Софт

Apache http

Рейтинг: 4.7/5.0 (682 проголосовавших)

Категория: Windows: Web серверы

Описание

Apache HTTP Server

Apache HTTP Server

Декабрь 31, 2012 0

Apache HTTP Server — свободный веб-сервер (HTTPD). Apache является кроссплатформенным программным обеспечением, поддерживает операционные системы Linux, BSD, Mac OS X, Microsoft Windows, Novell NetWare, BeOS.

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

Архитектура Apache HTTP Server

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

Теоретически, ядро apache может функционировать в чистом виде, без использования модулей. Однако, функциональность такого решения крайне ограничена.

Ядро Apache полностью написано на языке программирования C.

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

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

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

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

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

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

Часть модулей использует в своей работе конфигурационные файлы операционной системы (например /etc/passwd и /etc/hosts).

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

  • Мультипроцессовые модули (MPM)

Для веб-сервера Apache существует множество моделей симметричной мультипроцессорности. Вот основные из них:

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

pre-fork — MPM, основанная на предварительном создании отдельных процессов, не использующая механизм threads.

perchild — гибридная модель, с фиксированным количеством процессов.

netware — мультипоточная модель, оптимизированная для работы в среде NetWare.

winnt — мультипоточная модель, созданная для операционной системы Microsoft Windows.

Apache-ITK — MPM, основанная на модели prefork. Позволяет запуск каждого виртуального хоста под отдельными uid и gid.

peruser — модель, созданная на базе MPM perchild. Позволяет запуск каждого виртуального хоста под отдельными uid и gid. Не использует потоки.

  • Система модулей

Apache HTTP Server поддерживает модульность. Существует более 500 модулей, выполняющих различные функции. Часть из них разрабатывается командой Apache Software Foundation, но основное количество — отдельными open source-разработчиками.

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

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

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

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

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

  • Механизм виртуальных хостов

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

Для каждого виртуального хоста можно указать собственные настройки ядра и модулей, ограничить доступ ко всему сайту или отдельным файлам. Некоторые MPM, например Apache-ITK позволяют запускать процесс httpd для каждого виртуального хоста с отдельными идентификаторами uid и guid.

Также, существуют модули, позволяющие учитывать и ограничивать ресурсы сервера (CPU, RAM, трафик) для каждого виртуального хоста.

Функциональные возможности Apache HTTP Server

  • Интеграция с другим программным обеспечением и языками программирования

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

К ним относятся:

PHP (mod_php).

Python (mod python, mod wsgi).

Ruby (apache-ruby).

Perl (mod perl).

ASP (apache-asp).

Tcl (rivet)

Кроме того, Apache поддерживает механизмы CGI и FastCGI, что позволяет исполнять программы на практически всех языках программирования, в том числе C, C++, Lua, sh, Java.

  • Безопасность

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

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

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

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

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

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

В некоторых MPM-модулях присутствует возможность запуска каждого процесса Apache используя различные uid и gid с соответствующими этим пользователям и группам пользователей.

Также, существует механизм suexec, используемый для запуска скриптов и CGI-приложений с правами и идентификационными данными пользователя.

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

Существуют внешние средства обеспечения безопасности, например mod_security.

  • Интернационализация

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

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

  • Обработка событий

Администратор может установить собственные страницы и обработчики для всех HTTP ошибок и событий, таких как 404 (Not Found) или 403 (Forbidden). В том числе существует возможность запуска скриптов и отображения сообщений на разных языках.

  • Server Side Includes

В версиях 1.3 и старше был реализован механизм Server Side Includes, позволяющий динамически формировать HTML-документы на стороне сервера.

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

Apache http:

  • скачать
  • скачать
  • Другие статьи, обзоры программ, новости

    Russian Apache Web-Server

    Свежую версию Apache-RUS можно получить по адресу ftp://apache.lexa.ru/pub/apache-rus/ ("старшая" часть номера версии, например 1.3.3, соответствует версии оригинального Apache, "младшая", например PL27.3, - так называемому patch level, т. е. версии русского модуля). Рекомендуется устанавливать те версии, которые зарекомендовали себя как "стабильные". Здесь настройка сервера описывается на примере Apache_1.3.3rusPL27.3.

    Итак, первым делом мы переписываем на свою машину архив (менее 1,5 Мбайт) и распаковываем его:

    После этого входим в созданный при распаковке каталог apache_1.3.3rusPL27.3 и запускаем сценарий configure:

    При необходимости сценарию можно в явной форме указать аргументы (их список выдается по команде configure -help). Так, если требуется установить сервер в иной каталог, нежели стандартный, нужно выполнить "configure -prefix=<path-to-apache>".

    Когда configure отработает, следует, как обычно, дать команды make и make install (эти действия выполняются пользователем root).

    Теперь сервер установлен в каталоге /usr/local/apache, но запускать его пока нельзя - сначала мы должны отредактировать файлы настройки httpd.conf, access.conf и srm.conf в каталоге /usr/local/apache/etc/ (начиная с версии 27.4 - /usr/local/apache/conf).

    Настройка конфигурационных файлов Web-сервера - самый ответственный шаг при его установке. Здесь мы рассмотрим только наиболее распространенные директивы и их параметры, поскольку полный перечень с описанием займет не один десяток страниц. Сервер перечитывает конфигурационные файлы при запуске, а также при получении сигнала -HUP (жесткий рестарт) или -uSR1 (мягкий рестарт). Если сервер находится в рабочем состоянии, то при изменении конфигурации его рекомендуется перезапустить командой

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

    Файл access.conf

    В access.conf содержатся директивы, описывающие права доступа к каталогам и файлам Web-сервера. Прежде всего решите, в каком каталоге будут храниться документы. По умолчанию это /usr/local/apache/share/htdocs, однако многие администраторы предпочитают размещать документы начиная с каталога /www/<имя_сервера>/, поскольку при такой организации проще ориентироваться в структуре файлов. Пусть, например, мы создали каталоги:

    Они будут корневыми для соответствующих виртуальных серверов.

    Файл access.conf может содержать секции Directory, Location и Files, которые ограничены одноименными директивами. В параметрах этих директив могут использоваться символы "?" и "*". а также регулярные выражения, предваряемые тильдой, например <Directory

    "^/www.+/a?server">. В секции Directory помещаются инструкции, относящиеся к определенному каталогу на диске, в секции Location - относящиеся к виртуальному пути, в секции Files - относящиеся к файлу или группе файлов.

    Различие между секциями Directory и Location состоит в том, что первая относится к каталогам на диске, вторая - к виртуальному пути (URL), который браузер запрашивает у Web-сервера. И в той, и в другой могут присутствовать директивы order, allow и deny, которые позволяют ограничить доступ к каталогу или URL с различных машин.

    Следующие две директивы относятся к секции <Directory>.

    Options [options. ]

    Возможные значения параметров:
    • ExecCGI - разрешить выполнение CGI-сценариев в данном каталоге и его поддереве;
    • FollowSymLinks - разрешить переходы по символическим ссылкам (создаваемым командой ln);
    • Includes - разрешить SSI (Server Side Includes);
    • Indexes - разрешить выдачу листинга каталога, если в нем нет файла index.html (или файла индекса, заданного директивой DirectoryIndex);
    • MultiViews - разрешить поддержку многих языков; по умолчанию она отключена, и включать ее, как правило, не нужно; поддержка перекодирования "на лету" для русского языка устанавливается с помощью других директив, которые мы рассмотрим позже;
    • All - установить сразу все перечисленные режимы кроме MultiViews.

    При отсутствии специальных требований к безопасности вполне допустимо указать "Options All" в секции <Directory /www>; в противном случае нужно описать параметры каждого каталога отдельно.

    AllowOverride [options. ]

    Большинство директив могут задаваться не только в конфигурационных файлах сервера, но и в файлах .htaccess в каталогах сервера. Директива AllowOverride определяет набор директив, допустимых в файлах .htaccess. Параметры могут быть указаны следующие:

    AuthConfig - разрешить установку авторизации по имени пользователя и паролю;

    FileInfo - разрешить директивы, отвечающие за типы документов;

    Indexes - разрешить директивы, связанные с листингом каталогов;

    Limit - разрешить команды allow и deny, которые ограничивают доступ к файлам в зависимости от адреса клиентского компьютера;

    Options - разрешить описанную выше директиву Options.

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

    Однако во многих случаях (в частности, когда права на изменение содержимого сервера есть только у администратора) файл access.conf может выглядеть так, как в листинге 1 .

    Файл srm.conf

    Файл srm.conf содержит директивы, связанные с общими настройками структуры каталогов сервера. Как правило, в нем достаточно изменить лишь несколько строк.

    DocumentRoot <первый каталог сервера>

    Путь к каталогу по умолчанию, индексный файл которого пользователь получит при обращении к серверу (http://<имя_сервера>/). Эту директиву следует задать и для каждого из виртуальных серверов (в секции <VirtualHost> файла httpd.conf).

    UserDir <имя пользовательского каталога>

    Каталог, в котором пользователи должны размещать свои файлы, чтобы они были доступны по адресу http://<имя_сервера>/

    <имя_пользователя>/. Стандартно public_html. Иногда, чтобы облегчить жизнь пользователям, администраторы дают директиву "UserDir www".

    DirectoryIndex <список файлов индекса>

    Файл индекса - это тот файл, который будет передан клиенту при обращении к каталогу. Если указать несколько имен, сервер будет искать подходящий файл "слева направо". По умолчанию список содержит всего одно имя - index.html, но принято добавлять в него и другие распространенные имена индексных файлов. Например, директива может иметь вид: DirectoryIndex .index.html index.html index.htm index.cgi index.shtml home.html home.htm default htm default html

    Чтобы включить на сервере поддержку CGI-сценариев, следует убрать знак комментария перед директивами ScriptAlias и AddHandler cgi-script .cgi. Первая задает каталог на диске, в котором будут храниться исполняемые программы, а вторая определяет, что все файлы с расширением .cgi должны обрабатываться как сценарии.

    Директива ErrorDocument позволяет заменять стандартные сообщения сервера об ошибках на свои. Например, в случае самой распространенной ошибки - 404 (файл не найден) - считается хорошим тоном выдавать пользователю страницу с предложением продолжить свой путь по серверу или форму для поиска по узлу. Реализуется это достаточно просто: в настройках сервера мы убираем знак комментария со строки

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

    Файл httpd.conf

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

    Директива Port, помещенная в самом начале файла, определяет номер порта для http-сервера; по умолчанию это 80. При необходимости можно приписать серверу другой порт или несколько портов, для чего служит директива Listen.

    Директива HostnameLookups с параметром on или off включает или, соответственно, отключает преобразование численных IP-адресов клиентов, получивших документы с сервера, в доменные имена. Такое преобразование несколько замедляет работу сервера, но при числе посещений менее 10 000 в сутки это, как правило, практически не заметно.

    Директивы User и Group задают пользователя, который будет администрировать сервер. С точки зрения безопасности нежелательно указывать здесь существующего пользователя, имеющего доступ к каким-либо другим ресурсам или файлам. Лучше создать отдельного пользователя и группу специально для http-сервера, например:

    Директивы ServerRoot, ErrorLog, CustomLog определяют соответственно корневой каталог http-сервера, путь к журналу регистрации ошибок (error_log) и путь к общему журналу обращений к серверу (access_log).

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

    Настройка виртуальных серверов в файле httpd.conf

    В большинстве случаев один http-сервер способен обрабатывать запросы, поступающие на различные, так называемые виртуальные, Web-серверы. Виртуальные серверы могут иметь как один и тот же IP-адрес, но разные доменные имена, так и разные IP-адреса. С точки зрения пользователя второй вариант чуть более предпочтителен, поскольку запрос к серверу, отличающемуся от основного только доменным именем, должен содержать его имя, а некоторые старые браузеры, не поддерживающие протокол HTTP/1.1 (например, Microsoft Internet Explorer 2.0), не включают в запрос эту информацию. Однако такие браузеры выходят из употребления (сейчас их уже менее 0,5% общего числа); с другой стороны, выделение собственного IP-адреса каждому виртуальному серверу может быть неоправданной растратой адресного пространства компании.

    Для описания адресов и доменных имен виртуальных серверов служат директивы ServerName, ServerAlias, NameVirtualHost и VirtualHost. Они необходимы, только если вам нужно установить более одного виртуального сервера.

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

    Директива ServerName, находящаяся вне секций VirtualHost, определяет имя основного сервера, т. е. сервера, корневой каталог которого задан директивой DocumentRoot в файле srm.conf. Виртуальные серверы наследуют настройки основного; при необходимости специальной настройки соответствующие директивы помещаются в секции VirtualHost, относящейся к данному серверу. Допустимы любые директивы, которые могут встретиться в файлах httpd.conf и srm.conf, например DocumentRoot, ErrorLog, CustomLog, Location, ServerAdmin.

    Из листинга 3 видно, как используется директива ServerAlias, если необходимо создать несколько виртуальных серверов с одинаковым содержанием. После того как вы занесете в конфигурационные файлы информацию об имеющихся на диске виртуальных серверах (разумеется, они должны быть описаны и в конфигурационных файлах DNS), можно приступить к последнему шагу настройки Apache-RUS.

    Настройка перекодирования русскоязычных документов

    Модуль поддержки русских кодировок был разработан в 1996 г. Дмитрием Крюковым (dvk@stack.net ), а с февраля 1997 г. поддерживается рабочей группой Apache-RUS Team во главе с Алексеем Тутубалиным (lexa@ lexa.ru ). За время своего развития модуль претерпел множество изменений и теперь обладает практически неограниченными возможностями настройки для любой конкретной конфигурации.

    Инструкции, отвечающие за перекодирование, разделяются естественным образом на три группы. К первой относятся две директивы, указывающие, в какой кодировке хранятся файлы на диске: CharsetSourceEnc <кодировка> и CharsetByExtension <кодировка> <расширение1> <расширение2>.

    Например, файл httpd.conf может содержать строки:

    Такая запись означает, что все файлы хранятся на диске в кодировке koi8-r; исключение составляют текстовые файлы с расширением txt, для которых используется Windows-1251.

    Если кодировок более одной и документы в каждой кодировке хранятся в своем каталоге, директивы CharsetSourceEnc помещаются в соответствующие секции <Location> либо в файлы .htaccsess внутри каталогов.

    Вторую группу составляют директивы CharsetDecl, CharsetAlias CharsetRecodeTable и CharsetWideRecode Table, которые определяют названия кодировок, их синонимы и таблицы перекодирования. Все они размещаются в секции <IfModule mod_charset.c> - </IfModule> и в большинстве случаев не нуждаются в изменении.

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

    Принято, чтобы при попадании на русскоязычный сервер пользователь получал страницу в "своей" кодировке, определяемой автоматически на основе той информации об операционной системе, которую передает серверу браузер: например, установив, что пользователь работает в Windows, сервер выдает ему страницу в кодировке Windows-1251, а установив, что он работает в Unix, выдает страницу в koi8. Если выбранная таким образом страница не подходит, клиент может сменить кодировку вручную. Основных схем выбора три: по префиксу каталога, по имени виртуального сервера и по номеру порта. У каждой из них есть свои преимущества и свои недостатки.

    Для организации выбора кодировки по префиксу каталога нужно либо внести в секцию VirtualHost строку вида

    либо создать в соответствующем каталоге символическую ссылку на себя:

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

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

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

    Чтобы применить выбор по номеру порта, необходимо в файле httpd.conf удалить директиву Port и снять комментарии со строк

    Номера портов не очень важны. В стандартной настройке Apache-RUS нумерация, как видим, начинается с 8100, но чаще ее начинают с 8000 или 8080.

    Данная схема не требует внесения дополнительных записей в DNS и позволяет работать с виртуальными серверами даже клиентам, которые не поддерживают протокол HTTP/1.1, - ведь кодировка выбирается исходя из числа, указывающего на номер порта Web-сервера (по умолчанию это 80). Однако сетевые брандмауэры иногда запрещают работу с определенными портами, и если таким брандмауэром защищена сеть клиента, он не сможет установить соединение с вашим сервером. К сожалению, подобная ситуация возникает чаще, чем хотелось бы.

    Схема выбора кодировки задается директивой CharsetSelectionOrder. Ее параметры определяют порядок применения правил выбора. Так, выбору по префиксу каталога соответствует строка

    Выбору по имени домена - строка

    Для выбора по номеру порта следует записать

    Чтобы документы, кодировка которых была выбрана автоматически, не оседали в кэшах прокси-серверов, Apache-RUS дает им специальный HTTP-заголовок, запрещающий кэширование. В результате при возврате на страницу (например, по кнопке Back) она считывается с сервера заново, что, во-первых, замедляет работу, а во-вторых (и это более серьезная проблема) очищает все текстовые формы, которые были на странице (то же происходит при использовании JavaScript). Разрешить кэширование позволяет директива CharsetDisableForcedExpires On, которая задается в секции <Location> для данного виртуального пути или в соответствующем файле .htaccess, но тогда возникает риск, что пользователи иногда будут получать страницы в "чужой" кодировке. Существуют и промежуточные варианты: например, можно установить CharsetDisableForcedExpires On (в секции <Files>) только для тех документов, которые содержат формы, окна или JavaScript-сценарии.

    Для полного отключения перекодирования в каталоге или на виртуальном сервере служит директива Charset Disable On.

    При выборе кодировки по имени сервера или по префиксу каталога хорошим тоном является использование для графических файлов абсолютных ссылок с указанием имени сервера (например, <img src="http://images.rmt.ru/%20picture.jpg">). Тогда при переходе клиента от основного сервера к выбранной кодировке изображения будут браться из локального кэша браузера, а не перечитываться заново. Это особенно актуально при большом объеме графической информации на сервере.

    Запуск сервера

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

    Если в конфигурационных файлах есть серьезные ошибки, сервер не запустится, а на экран будет выведено соответствующее сообщение. В любом случае после запуска сервера имеет смысл просмотреть файлы error_log и access_log, которые находятся в каталоге logs. Для проверки работоспособности сервера достаточно создать в его корневом каталоге файл index.html и обратиться из браузера по адресу сервера. Правильную установку режимов перекодирования следует проверять с помощью браузеров для различных операционных систем. Не забудьте добавить Apache в список программ, запускаемых при старте системы. Успехов вам в пополнении русского Web-пространства!

    Артем Подстрешный - программист, работает в компании "Радио-МГУ". В "Мире ПК" опубликована его статья "Имена Internet". E-mail: art@radio-msu.net ; http://www.radio-msu.net/

    Apache HTTP Server

    Apache HTTP Server

    Apache HTTP Server – проект, развиваемый The Apache Software Foundation. в рамках которого разрабатывается кроссплатформенный HTTP сервер с открытым исходным кодом. Входит в состав LAMP и XAMPP.

    Для применения изменений в настройках необходимо перезапустить демон Apache:

    До версии Ubuntu Raring (13.04) включительно

    Виртуальные хосты

    Файлы настроек виртуальных хостов хранятся в /etc/apache2/sites-available. По умолчанию в Apache уже настроен один виртуальный хост. Его настройки лежат в файле default (в новых версиях файл может называться 000-default.conf). Вы можете использовать этот виртуальный хост в качестве примера.

    Настройки модулей хранятся в директории /etc/apache2/mods-available. Для включения или отключения модулей используются a2enmod и a2dismod соответственно.

    Модуль mod_userdir позволяет использовать директории находящиеся в домашних директориях пользователей для хранения веб страниц. По умолчанию Apache ищет запрашиваемые страницы в директории

    Для включения поддержки PHP5 в качестве модуля Apache необходимо установить пакет libapache2-mod-php5.

    Настройка HTTPS в Apache

    Веб-сервер Apache полностью поддерживает работу по HTTPS. Для того, чтобы активировать поддержку HTTPS на уже установленном Apache необходимо выполнить следующее.

    Создание ключа и ssl-сертификата

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

    Для создания ключа и сертификата вводим команду:

    На вопрос «Enter PEM pass phrase:» отвечаем паролем, подтверждаем и запоминаем. На все последующие вопросы отвечаем произвольно, можно просто щелкать по Enter соглашаясь с предложенными вариантами, только на вопрос «Common Name (eg, YOUR name) []:» отвечаем именем сайта, для которого создаем сертификат, например www.example.com.

    После ответа на все вопросы в директории должны появиться два новых файла - server.pem и server.crt (ключ и сертификат, соответственно).

    Чтобы использовать сгенерированный ключ нужно знать пароль введенный нами, и Apache будет спрашивать его у нас при загрузке, а к чему нам лишние вопросы от демонов. ) Поэтому снимаем пароль с ключа:

    Скопируем их в /etc/ssl и назначим файлу ключа права чтения только администратору:

    Настройка Apache

    Для начала необходимо активировать mod_ssl.

    А затем включить настройки HTTPS сайта по умолчанию:

    Теперь необходимо отредактировать файл с настройками HTTPS сайта по умолчанию, указав в нём пути к вашим сертификатам. Сам файл называется /etc/apache2/sites-enabled/default-ssl (или /etc/apache2/sites-enabled/default-ssl.conf ).

    Аутентификация средствами Apache Web Server - #Записки о Unix

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

    Для начала давайте разберемся с определениями:

    Аутентификация -  процедура проверки соответствия некоего лица и его учетной записи в компьютерной системе. В простейшем случае проверка происходит с помощью пароля.

    Аутентификацию не следует путать с идентификацией и авторизацией.

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

    Подробнее, можете ознакомится здесь.

    С определениями разобрались, переходим к серверу.

    Apache поддерживает 2 вида аутентификации: Basic-аутентификацию (Базовая аутентификация) и Digest-аутентификацию (Дайджест аутентификация). Подробно механизмы аутентификации описаны в RFC 2617 .

    Аутентификацию можно настроить непосредственно в конфигурационном файле Apache сервера - httpd.conf или в отдельном файле, помещенном в директорию с index страницей сайта. Имя файла - .htaccess .

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

    Внимание! При настройке посредством .htaccess. необходимо сначала убедиться, что директива AllowOverride в файле httpd.conf разрешает получение настроек из файла .htaccess. Для подроробностей обратитесь к документации Apache.

    Рассмотрим механизм Basic-аутентификации:

    Клиент, обращаясь к странице защищенного сайта к примеру test.ru отсылает запрос типа

    GET /site/private HTTP/1.0

    Сервер присылает ответ:

    HTTP/1.1 401 Unauthorized

    WWW-Authenticate: Basic realm="private"

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

    Вводим логин - пароль и нажимаем кнопку "Отправить", на что браузер сервер шлет запрос следующего вида:

    GET /site/private HTTP/1.0

    Authorization: Basic YWRtaW46MTIzNDU=

    В зависимости от правильности введённых данных сервер, либо разрешит доступ к защищаемому ресурсу, либо запретит.

    От теории переходим к практике.

    Создание базовой Аутентификации:

    1) Создаем файл с паролями пользователей htpasswd

    2) Прописать защищаемый ресурс в конфигурацию Apache (в файл httpd.conf или в файле .htaccess)

    3) Создать файл для работы с группами и настроить групповой доступ (этот щаг не обязателен).

    1) Для создания файла с паролямя имеется в наличии утилита, входящая в стандартную поставку сервера Apache .

    htpasswd -c /var/www/html/site/.htpasswd administrator

    разберем что сделает данная команда:

    - создает новый файл .htpasswd в директории с сайтом site.  Если файл отсутствует, то будет создан новый, если файл имеется, то он затрется, а на его место запишется новый с указанным пользователем, а данном случае "administrator".  За создание нового файла отвечает ключ "-с".

    Чтобы добавить в файл еще одного пользователя, например: tolik выполняем предыдущую команду, но уже без "-с" :

    htpasswd -c /var/www/html/site/.htpasswd tolik

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

    В результате правильного выполнения команд, файл .htpasswd заполнится и примет вид:

    пользователь:хеш пароля пользователя

    Рассмотрим, остальные ключи утилиты htpasswd :

    -n Результат работы htpasswd (имя пользователя:хеш пароля) будет выведен на экран, а не в файл.

    -p Пароль хранится в виде обычного текста безо всякого шифрования. Данный формат поддерживается только в операционных системах Windows, Netware и BEOS (не рекомендую).

    -d Хеш пароля вычисляется с использованием стандартной Unix-функции CRYPT. Это алгоритм шифрования по умолчанию. Используется только на *nix серверах.

    -m Хеш пароля вычисляется по алгоритму MD5.

    -s Хеш пароля вычисляется по алгоритму SHA1.

    -D Заданный пользователь удаляется из файла с паролями.

    Все подробности можно узнать прочитав man htpasswd .

    2) Прописываем защищаемый ресурс в конфигурацию Apache (в файл httpd.conf или в файле .htaccess )

    AuthType - тип аутентификации Basic/Digest.

    AuthName - название для области, требующей авторизации. Это название появится в диалоговом окне ввода логина и пароля.

    AuthUserFile - местонахождение файла с паролями.

    AuthGroupFile - местонахождение файла групп.

    Require - требования, необходимые для доступа к защищённой области. Так, значение valid-user позволит произвести авторизацию для любого пользователя, прописанного в файле .htpasswd.

    Пример: 

    < Directory "/var/www/html/secret">  

       AuthType Basic

       AuthName "Private Area"

       AuthUserFile /var/www/html/site/.htpasswd

       Require valid-user

    Теперь проделываем все тоже самое, но в варианте с  файлом .htaccess .

    Содержание файла для нашего примера будет следующим:

      AuthType Basic

      AuthName "Private Area"

      AuthUserFile /var/www/html/secret/.htpasswd

      Require user administrator tolik

    Пример похож на предыдущий, но есть одно отличие. Доступ к секретной области сайта будет разрешён не для всех пользователей из файла .htpasswd. а только для пользователей administrator и tolik .

    3) Создаем файл для работы с группами и настраиваем групповой доступ.

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

    admins: administrator goga

    users: tolik vano

    т.е. у нас есть две группы пользователей admins и users. Членами группы admins являются пользователи administrator и goga. а членами группы users являются пользователи tolik. vano .

    AuthType Basic

    AuthName "Private Area"

    AuthUserFile /var/www/html/secret/.htpasswd

    AuthGroupFile /var/www/html/secret/.htgroup

    Require group admins

    В приведённом примере доступ к секретной области сайта имеют только члены группы admins .

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

    Digest-аутентификация.

    Digest-аутентификация представляет собой более продвинутый и сложный вид аутентификации, чем Basic-аутентификация. Главным отличием здесь является то, что логин-пароль пользователя пересылаются через сеть не в открытом виде, а шифруются по алгоритму MD5. Настройка Digest-аутентификации похожа на настройку Basic-аутентификации. Основные шаги остаются прежними:

    1) Создать файл с паролями.

    2) Прописать защищаемый ресурс в конфигурацию Apache (в файле httpd.conf или в файле .htaccess).

    3) Создать файл для работы с группами и настроить групповой доступ (этот пункт не является обязательным).

    1) Создаём файл с паролями.

    Файл паролей создаётся при помощи стандартной утилиты htdigest:

    htdigest -c [путь к файлу с паролями] [название секретной области] [имя пользователя]

    Ключ -c указывается при необходимости создать новый файл, а обязательный аргумент [название секретной области] - это наименование секретной области, которое позже будет указано в директиве AuthName.

    Настройка Apache

    Настройка Apache Файл "httpd.conf"

    Основной файл конфигурации этого сервера - "httpd.conf". Лежит он в каталоге "conf" в root-директории Apache. Вот над ним вам и придеться издеваться. Скажу сразу, если вы не понимаете английского, удалите из этого файла все комментарии и пояснения, оставьте только сами директивы (и закоментированные тоже); таким образом вы сможете быстрее находить нужную директиву, не роясь среди множества непонятных вам пояснений. Синтаксис файла очень простой: "директива значение", все строки не соответствующие этому виду можно удалить.

    Внимане! Некоторые директивы могут выглядеть так:

    и т. п. Эти строки удалять не нужно!

    Символ комментария в "http.conf" - "#" (решетка). Т. е. все символы, идущие в строке после "#" не воспринимаются сервером. Так вы можете добавлять собственные комментарии. Убирая этот символ перед закомментированными строками вы делаете их доступными для чтения сервером.

    Общие настройки

    Вам нужно будет сделать правку файла "httpd.conf". У некоторых директив изменить значение, другие раскомментировать, третьи добавить. Далее я приведу список директив и их значений, которые должны присутствовать в файле конфигурации Apache.

    Каталог с файлами сервера (не путать с "DocumentRoot"):

    Привязывает Apache к конкретному порту:

    Имя сервера (на работу это не влияет):

    Администратор сервера. Содержит ваш адрес электронной почты, который будет отображаться при некоторых ошибках сервера:

    Вам необходимо создать папки, где будут храниться ваши сайты. По умолчанию Apache устанавливает "DocumentRoot" - "%ServerRoot%/htdocs" (т. е. если вы установили Apache в папку "C:\Server\Apache", то "DocumentRoot" будет выглядеть так: "C:/Server/Apache/Apache2/htdocs"). Вы должны изменить значение "DocumentRoot" на "C:/Sites/home/localhost/www".

    Строго следуйте моим инструкциям, чтобы быть уверенными, что все это у вас потом заработает. Создайте на диске "C:" папку "Sites". В ней создайте каталог "home", уже в нем - "localhost", "neebet", "mysite". В каждую из этих папок ("localhost", "neebet", "mysite") положите каталоги "www" (для хранения html документов), "cgi" (для хранения cgi-скриптов), пустые файлы access.log (журнал доступа к серверу) и error.log (журнал ошибок сервера). Т. о. структура каталогов, в которых будут храниться ваши сайты должна выглядеть так:

    Зачем это нужно, поймете потом, а сейчас просто сделайте как я говорю.

    Далее замените блок "<Directory "C:/Server/Apache/Apache2/htdocs">" на следующее:

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

    Задание индексного файла для директории (этот файл сервер будет отображать при обращении к каталогу без указания имени файла):

    Настройки CGI

    Задание псевдонима для каталога с cgi-скриптами "C:\Sites\home\localhost\cgi". При указании пути вида http://localhost/cgi/ или http://localhost/cgi-bin/. Apache будет обращаться к каталогу "C:\Sites\home\localhost\cgi":

    Каталог "C:\Sites\home\localhost\cgi" также будет доступен вашим виртуальным хостам при обращении вида "http://имя_виртуального_хоста/cgi-bin/cgi-скрипт.bat". Напрмер, если вы введете в браузере http://neebet/cgi-bin/cgitest.bat. то будет выполнен код, находящийся в файле "C:\Sites\home\localhost\cgi\cgitest.bat", который также доступен по адресу http://localhost/cgi/cgitest.bat. У виртуальных хостов есть свой каталог для cgi-скриптов, доступный по адресу "http://имя_виртуального_хоста/cgi/cgi-скрипт.bat". Каталоги "cgi" не доступны для просмотра в браузере, и при прямом обращении к ним вы получите сообщение об ошибке "403".

    Указывает Apache, что файлы с расширением "cgi", "bat", "exe" нужно воспринимать как cgi-скрипты:

    Блок "<Directory "C:/Server/Apache/Apache2/cgi-bin">" замените на:

    Языковые настройки

    Остальные строки вида "AddLanguage lang .lang" можете закомментировать (если конечно вам не нужна поддержка этих языков):

    Устанавливает языковой приоритет: