Основные общие черты
Хотя программы веб-серверов различаются по способу реализации, большинство из них предлагают следующие основные общие функции.
- HTTP : поддержка одной или нескольких версий протокола HTTP для отправки версий ответов HTTP, совместимых с версиями клиентских HTTP-запросов, например HTTP / 1.0, HTTP / 1.1 плюс, если доступно, HTTP / 2 , HTTP / 3 ;
- Ведение журнала : обычно веб-серверы также имеют возможность регистрировать некоторую информацию о клиентских запросах и ответах сервера для файлов журнала в целях безопасности и статистики.
Вот несколько других популярных функций (лишь очень небольшой выбор):
- Аутентификация , дополнительная поддержка запроса авторизации (запрос имени пользователя и пароля ) перед предоставлением доступа к некоторым или всем ресурсам веб-сайта.
- Поддержка больших файлов , чтобы иметь возможность обслуживать файлы, размер которых превышает 2 ГБ в 32-битной ОС .
- Регулирование полосы пропускания , чтобы ограничить скорость ответов контента, чтобы не перегружать сеть и иметь возможность обслуживать больше клиентов.
- Виртуальный хостинг , позволяющий обслуживать множество веб-сайтов ( доменных имен ), используя только один IP-адрес .
Выступления
Чтобы улучшить взаимодействие с пользователем, веб-серверы должны быстро (как можно скорее) отвечать на запросы клиентов; если ответ содержимого не регулируется (конфигурацией) для некоторых типов файлов (например, больших файлов и т. д.), также необходимо как можно скорее отправить содержимое возвращаемых данных (высокая скорость передачи).
Для программного обеспечения веб-сервера основные ключевые статистические данные о производительности (измеренные при различной нагрузке клиентов и запросов на каждого клиента):
- количество максимальных запросов в секунду (RPS, аналогичноQPS, в зависимости от версии и конфигурации HTTP, типа HTTP-запросов и т. д.);
- время отклика с задержкой в сети (обычно в миллисекундах) для каждого нового клиентского запроса;
- пропускная способность в байтах в секунду (в зависимости от размера файла, кэшированного или некэшированного содержимого, доступной пропускной способности сети, типа используемого протокола HTTP и т. д.).
Выше трех показателей производительности могут заметно отличаться в зависимости от количества активных TCP-соединений, поэтому четвертый статистический показатель — это уровень параллелизма, поддерживаемый веб-сервером при определенной конфигурации веб-сервера, типе ОС и доступных аппаратных ресурсах.
И последнее, но не менее важное: конкретная модель сервера, используемая для реализации программы веб-сервера, может влиять на производительность и уровень масштабируемости, который может быть достигнут при большой нагрузке или при использовании высокопроизводительного оборудования (много процессоров, дисков и т. Д.).. Производительность веб-сервера обычно оценивается с помощью одного или нескольких доступных
инструментов автоматизированного нагрузочного тестирования .
Производительность веб-сервера обычно оценивается с помощью одного или нескольких доступных
инструментов автоматизированного нагрузочного тестирования .
Директива RedirectMatch
Описание: отправляет внешнее перенаправление на основе совпадения регулярного выражения текущего URL-адреса.
Синтаксис: RedirectMatch regex URL
Контекст: конфигурация сервера, виртуальный хост, каталог, .htaccess
Переопределить: FileInfo
Модуль: mod_alias
Эта директива эквивалентна Redirect, но использует регулярные выражения вместо простого сопоставления префиксов. Предоставленное регулярное выражение сопоставляется с URL-путём, и если он совпадает, сервер подставляет любые совпадения в скобках в заданную строку и использует её в качестве имени файла. Например, чтобы перенаправить все файлы GIF в файлы JPEG с одинаковыми именами на другом сервере, можно использовать:
RedirectMatch "(.*)\.gif$" "http://other.example.com$1.jpg"
Соображения, связанные с различием между Alias и AliasMatch, также применимы к различию между Redirect и RedirectMatch. Смотрите подробности в AliasMatch.
Как сгенерировать SSL сертификат в Windows
У меня веб-сервер установлен в папку C:\Server\bin\Apache24, поэтому если у вас он в другой директории, то подправьте команды под свои условия.
Откройте командную строку Windows (Win+x, далее выберите «Windows PowerShell (администратор)»). В командной строке введите команды:
cmd cd C:\Server\bin\Apache24\bin\ set OPENSSL_CONF=C:\Server\bin\Apache24\conf\openssl.cnf openssl.exe genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out localhost.key openssl.exe req -new -key localhost.key -out localhost.csr
При вводе последней команды появятся запросы на английском языке. Ниже следует их перевод.
You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. -----
Перевод:
Далее:
Country Name (2 letter code) :
Перевод:
Далее:
State or Province Name (full name) :
Перевод:
Далее:
Locality Name (eg, city) []:
Перевод:
Далее:
Organization Name (eg, company) :
Перевод:
Далее:
Organizational Unit Name (eg, section) []:
Перевод:
Далее:
Common Name (e.g. server FQDN or YOUR name) []:
Перевод:
Далее:
Email Address []:
Перевод:
Далее:
Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
Перевод:
Пожалуйста, введите следующие «дополнительные» атрибуты для отправки с вашим запросом сертификата Пароль запроса: Опциональное имя компании:
Теперь выполните команду:
openssl.exe x509 -req -days 365 -in localhost.csr -signkey localhost.key -out localhost.crt
В результате в каталоге C:\Server\bin\Apache24\bin\ должны появиться три новых файла:
- localhost.key
- localhost.csr
- localhost.crt
Из них нам понадобятся только два:
- localhost.key
- localhost.crt
Директива ScriptAlias
Описание: сопоставляет URL-адрес с расположением файловой системы и назначает цель как сценарий CGI.
Синтаксис: ScriptAlias путь-к-файлу|путь-к-директории
Контекст: конфигурация сервера, виртуальный хост, каталог
Статус: База
Модуль: mod_alias
Директива ScriptAlias имеет то же поведение, что и директива Alias, за исключением того, что, за исключением того, что она помечает целевой каталог как содержащий сценарии CGI, которые будут обрабатываться обработчиком cgi-script mod_cgi. URL-адреса с чувствительным к регистру (%-декодированным) путём, начинающимся с URL-путь, будут сопоставлены сценариям, начинающимся со второго аргумента, который является полным путём в локальной файловой системе.
ScriptAlias "/cgi-bin/" "/web/cgi-bin/"
Запрос http://example.com/cgi-bin/foo заставит сервер запустить скрипт /web/cgi-bin/foo. Эта конфигурация по существу эквивалентна:
Alias "/cgi-bin/" "/web/cgi-bin/" <Location "/cgi-bin"> SetHandler cgi-script Options +ExecCGI </Location>
ScriptAlias также можно использовать вместе с имеющимся у вас скриптом или обработчиком. Например:
ScriptAlias "/cgi-bin/" "/web/cgi-handler.pl"
В этом сценарии все файлы, запрошенные в /cgi-bin/, будут обрабатываться файлом, который вы настроили, это позволяет вам использовать свой собственный обработчик. Вы можете использовать это как оболочку для CGI, чтобы вы могли добавлять контент или какое-либо другое действие на заказ.
Безопаснее не помещать скрипты CGI в DocumentRoot, чтобы случайно не раскрыть их исходный код, если конфигурация когда-либо изменится. ScriptAlias упрощает это, отображая URL-адрес и одновременно определяя скрипты CGI. Если вы все же решили разместить свои скрипты CGI в каталоге, уже доступном из Интернета, не используйте ScriptAlias. Вместо этого используйте <Directory>, SetHandler и Options, как в:
<Directory "/usr/local/apache2/htdocs/cgi-bin"> SetHandler cgi-script Options ExecCGI </Directory>
Это необходимо, поскольку несколько URL-путей могут отображаться в одно и то же расположение файловой системы, потенциально обходя ScriptAlias и открывая исходный код сценариев CGI, если они не ограничены разделом Directory.
Если директива ScriptAlias используется в разделе <Location> или <LocationMatch> с опущенным URL-путем, тогда параметр URL будет интерпретироваться с использованием синтаксиса выражений.
Этот синтаксис доступен в Apache 2.4.19 и новее.
<Location "/cgi-bin">
ScriptAlias "/web/cgi-bin/"
</Location>
<LocationMatch "/cgi-bin/errors/(?<NUMBER>+)">
ScriptAlias "/web/cgi-bin/errors/%{env:MATCH_NUMBER}.cgi"
</LocationMatch>
mod_security
Мой любимый модуль и, пожалуй, после mod_rewrite самый востребованный.
ModSecurity — это WAF — web application firewall, т.е. файервол для веб-приложений. Его смысл заключается в том, что он проверяет все приходящие на веб-сервер запросы и отфильтровывает те из них, которые соответствуют правилам безопасности. WAF (файервол для веб-приложений) может предотвратить атаки самого разного рода — инъекции (инжекты) в базы данных, межсайтовый скриптинг, на известные уязвимости популярных движков и очень многое другое, даже, например, в случае с Shellshock может помочь ModSecurity.
Статьи:
- Как установить ModSecurity (mod_security) на Apache (на Windows)
- Как усилить веб-сервер Apache с помощью mod_security и mod_evasive на CentOS
Домашняя страница: http://www.modsecurity.org/
Свой веб интерфейс к 1С: побеждаем CORS на IIS, сохраняя авторизацию
Если «веб морда» расположена не по тому же адресу, что и публикация 1С (что часто бывает, например, при разработке, публикация 1С на http://localhost/1c, а разрабатываемое веб-приложение на http://localhost:8080) или, например, мы заходим на веб приложение то по ip адресу, то по имени сервера, или просто веб сервер и сервер, на котором опубликована 1С — это разные сервера, то для большинства запросов от браузера к 1С срабатывает политика CORS, которая заключается в том, что браузер сначала посылает запрос OPTIONS, на который сервер должен ответить определенным образом, заголовками, содержащими разрешения, а потом уже (если разрешение есть), браузер посылает основной запрос. В случае, когда в публикации 1С (default.vrd) жестко прописан логин и пароль, разрулить ситуацию можно средствами 1С. В случае же, когда нужно сохранить авторизацию (или используется стандартный интерфейс odata), начинаются проблемы.
Apache Default WEB Page
В процессе выполнения стандартной инсталляции web сервера Apache в Ubuntu server создается тестовый сайт, который служит для проверки работоспособности веб сервера после его установки. Этот сайт, по умолчанию, сконфигурирован так, что разрешает обращения из браузера только к файлам и каталогам внутри /var/www директории Ubuntu server. Если, по завершению инсталляции Apache, вы откроете в браузере веб страницу по адресу IP вашего web сервера, то увидите стартовую страницу сервера — Apache2 Ubuntu Default Page. Это будет, в первую очередь, говорить о том, что Apache удачно установился и работает. Эта страница физически располагается на сервере в файле /var/www/html/index.html и за ее настройку и вывод в браузере отвечает конфиг виртуального хоста по умолчанию (/etc/apache2/sites-available/000-default.conf), который определяет виртуальный хост(сайт) для каталога /var/www/html и создается в ходе инсталляции сервера Apache. Соответственно, если вы разместите ваши файлы в этой папке, то они будут обрабатываться web сервером. Также на этой Default Page в секции Configuration Overview вы увидите схематическое представление структуры конфигурационных файлов сервера. Здесь нужно понимать, что структура, названия и расположения конфигов Apache в Ubuntu отличаются от общепринятой схемы, что сделано для удобства управления сервером. Но тут есть один нюанс, который заключается в том, что если вы ранее не были знакомы с организацией каталогов в домашней директории Apache на Ubuntu, то эта схема может вас только запутать, т.к. в ней представлены не все папки, а только каталоги, в которых располагаются символьные ссылки на активированные файлы конфигурации. Поэтому, для более правильного понимания, смотрите полную схему каталогов и фалов домашней директории web сервера Apache расположенную ниже в этой статье. Из ценного в секции веб страницы Apache — это ссылки на man’ы Debian для команд a2enmod, a2dismod, a2ensite, a2dissite, a2enconf, a2disconf, которые используется для активации и деактивации тех или иных видов файлов конфигурации и будут детально описаны . Так же здесь сказано, что для передачи команд web серверу ( started/stopped etc.) нужно обращаться к /etc/init.d/apache2 или к apache2ctl, что так же является особенностью сервера в Ubuntu. На сервере Ubuntu в файле /usr/share/doc/apache2/README.Debian.gz вы сможете найти полную документацию по Apache.
Сертификаты SSL
SSL сертификаты можно разделить на два вида: валидные и самоподписанные.
Сертификат SSL можно сгенерировать у себя на компьютере. Причём можно сгенерировать для любого доменного имени. Но к таким сертификатам у веб-браузеров нет доверия. Поэтому если открыть сайт, защищённый таким сертификатом, то веб-браузер напишет ошибку, что сертификат получен из ненадёжного источника и либо запретит открывать этот сайт, либо предложит перейти на сайт на ваш страх и риск. Это так называемые «самоподписанные сертификаты». Чтобы браузер не выдавал ошибку о ненадёжного сертификате, его нужно добавить в список доверенных. Такие сертификаты подойдут для тестирования веб-сервера и обучению настройки веб-сервера для работы с SSL и HTTPS. Ещё такой сертификат можно использовать на сайте, к которому имеет доступ ограниченный круг лиц (несколько человек) — например, для сайтов в локальной сети. В этом случае они все могут добавить сертификат в доверенные.
Для реального сайта такой сертификат не подойдёт.
Для рабочего окружения нужен валидный сертификат, его можно получить двумя способами:
1) получить тестовый сертификат на 3 месяца (затем его можно продлить)
2) купить сертификат — в этом случае он действует от года и более
Валидный сертификат отличается от самоподписанного тем, что сторонний сервис удостоверяет подлинность этого сертификата. Собственно, оплачивается именно эта услуга удостоверения, а не выдача сертификата.
Данная статья посвящена вопросу, как настроить Apache в Windows для работы с протоколом HTTPS, будет показано, как подключить SSL сертификаты к Apache в Windows. Поэтому для целей тестирования и обучения нам хватит самоподписанного сертификата.
Что такое веб-сервер?
Обработка файлов, обработка баз данных, почты и веб-сервер использует различные виды серверного программного обеспечения. Каждое из этих приложений может иметь доступ к файлам, хранящимся на реальном сервере и использовать их в различных целях.
Работа веб-сервера – обслуживать сайт в интернете. Для этого он выполняет роль посредника между компьютером сервера и компьютером клиента. Он берёт контент с сервера на каждый запрос пользователя и доставляет его в сеть.
Самой большой задачей веб-сервера является одновременное обслуживание различных запросов от многих пользователей. Веб-сервер обрабатывает файлы написанные на разных языках программирования, таких как PHP, Python, Java и другие.
Он превращает их в статический файл HTML и отдаёт их на обслуживание в браузер пользователя. Когда вы слышите словосочетание веб-сервер, думайте о нём, как об инструменте для коммуникации между сервером и клиентом.
Как попробовать
Вы можете запустить собственный веб-сервер прямо на своём компьютере за пять минут. Самый простой способ — скачать MAMP: это пакет для веб-разработчика, в который встроен менеджер баз данных, веб-сервер, движок PHP и другие полезные для веба штуки. Работает так:
- Скачиваете MAMP для своей операционки.
- Устанавливаете.
- Запускаете программу и в ней говорите Start.
- MAMP скажет вам, что сервер запущен, откликается по такому-то адресу и смотрит в такую-то директорию на вашем компе (всё это можно настроить, а можно оставить так). Скорее всего, ваш веб-сервер начнёт откликаться из браузера по запросу http://localhost.
- Зайдите на http://localhost/MAMP/ — там будет вся информация о вашем сервере вплоть до ключей от базы данных и ссылки на запуск инструмента администрирования БД phpMyAdmin.
Далее можно, например, скачать дистрибутив Вордпресса, распаковать его в папку, где работает ваш сервер, и попробовать эту штуку установить. Придётся создавать БД через phpMyAdmin, но об этом в другой раз.
Обратите внимание: MAMP — это локальный сервер. Из внешнего интернета его не видно
Если хотите настроить видимый из внешнего интернета сайт, это несколько сложнее.
Текст:
Михаил Полянин
Редактор:
Максим Ильяхов
Художник:
Даня Берковский
Корректор:
Ирина Михеева
Вёрстка:
Кирилл Климентьев
Соцсети:
Виталий Вебер
Рыночная доля
ЛАМПА (комплект программного обеспечения) (здесь дополнительно с Squid ), состоящий исключительно из свободного и открытого программного обеспечения , является высокая производительность и решение высокой доступности для тяжелых условий эксплуатации для враждебной среды
Диаграмма: Рыночная доля всех сайтов основных веб-серверов 2005–2018 гг.
Февраль 2021 г.
| Продукт | Продавец | Процентов |
|---|---|---|
| nginx | NGINX, Inc. | 34,54% |
| Apache | Apache | 26,32% |
| IIS | Microsoft | 6.5% |
| OpenResty | Фонд программного обеспечения OpenResty | 6,36% |
| Сервер Cloudflare | Cloudflare, Inc. | 5,0% |
Все остальные веб-серверы используются менее чем 5% веб-сайтов.
Февраль 2020 г.
| Продукт | Продавец | Процентов |
|---|---|---|
| nginx | NGINX, Inc. | 36,48% |
| Apache | Apache | 24,5% |
| IIS | Microsoft | 14,21% |
| OpenResty | Фонд программного обеспечения OpenResty | 4,00% |
| GWS | 3,18% | |
| Сервер Cloudflare | Cloudflare, Inc. | 3,0% |
Все остальные веб-серверы используются менее чем 3% веб-сайтов.
Февраль 2019 г.
| Продукт | Продавец | Процентов |
|---|---|---|
| IIS | Microsoft | 28,42% |
| Apache | Apache | 26,16% |
| nginx | NGINX, Inc. | 25,34% |
| GWS | 1,66% |
Все остальные веб-серверы используются менее чем 1% веб-сайтов.
Июль 2018 г.
| Продукт | Продавец | Процентов |
|---|---|---|
| IIS | Microsoft | 34,50% |
| Apache | Apache | 27,45% |
| nginx | NGINX, Inc. | 24,32% |
| GWS | 1,20% |
Все остальные веб-серверы используются менее чем 1% веб-сайтов.
Февраль 2017 г.
| Продукт | Продавец | Январь 2017 г. | Процентов | Февраль 2017 г. | Процентов | Изменять | Цвет диаграммы |
|---|---|---|---|---|---|---|---|
| IIS | Microsoft | 821 905 283 | 45,66% | 773 552 454 | 43,16% | -2,50 | красный |
| Apache | Apache | 387 211 503 | 21,51% | 374 297 080 | 20,89% | -0,63 | чернить |
| nginx | NGINX, Inc. | 317 398 317 | 17,63% | 348 025 788 | 19,42% | 1,79 | зеленый |
| GWS | 17 933 762 | 1,00% | 18 438 702 | 1,03% | 0,03 | синий |
Февраль 2016 г.
| Продукт | Продавец | Январь 2016 | Процентов | Февраль 2016 г. | Процентов | Изменять | Цвет диаграммы |
|---|---|---|---|---|---|---|---|
| Apache | Apache | 304 271 061 | 33,56% | 306 292 557 | 32,80% | 0,76 | чернить |
| IIS | Microsoft | 262 471 886 | 28,95% | 278 593 041 | 29,83% | 0,88 | красный |
| nginx | NGINX, Inc. | 141 443 630 | 15,60% | 137 459 391 | 16,61% | -0,88 | зеленый |
| GWS | 20 799 087 | 2,29% | 20 640 058 | 2,21% | -0,08 | синий |
Apache, IIS и Nginx — наиболее часто используемые веб-серверы во всемирной паутине.
Сервер 1С:Предприятие на Ubuntu 16.04 и PostgreSQL 9.6, для тех, кто хочет узнать его вкус. Рецепт от Капитана
Если кратко описать мое отношение к Postgres: Использовал до того, как это стало мейнстримом.
Конкретнее: Собирал на нем сервера для компаний среднего размера (до 50 активных пользователей 1С).
На настоящий момент их набирается уже больше, чем пальцев рук пары человек (нормальных, а не фрезеровщиков).
Следуя этой статье вы сможете себе собрать такой же и начать спокойную легальную жизнь, максимально легко сделать первый шаг в мир Linux и Postgres.
А я побороться за 1. Лучший бизнес-кейс (лучший опыт автоматизации предприятия на базе PostgreSQL).
Если, конечно, статья придется вам по вкусу.
Настройка виртуальных хостов
Важной особенностью Apache является возможность создания виртуальных хостов, настраиваемых независимо друг от друга, что позволяет размещать на VDS-сервере сразу несколько сайтов. За конфигурацию каждого сайта будет отвечать конкретный виртуальный хост
Даже если на начальном этапе Вы планируете размещать только один сайт на сервере, мы рекомендуем в любом случае использовать виртуальные хосты. Это обеспечит Вам удобство администрирования и обслуживания Вашего проекта, а в дальнейшем и легкость расширения при необходимости.
По умолчанию Apache содержит стандартный файл конфигурации 000-default.conf, который хранится в директории /etc/apache2/sites-available.
Файлы наших виртуальных хостов будут храниться здесь же, и мы сформируем их на основе 000-default.conf.
Однако сначала мы отключим стандартный файл конфигурации командой:
$ sudo a2dissite 000-default
Теперь скопируем его содержимое в файл, который будет содержать настройки Вашего сайта.
В наших примерах в качестве имени сайта мы будем использовать site1, Вам необходимо заменить это значение на имя Вашего сайта.
Вы можете давать конфигурационным файлам любые названия, но мы рекомендуем обозначать их так, чтобы в дальнейшем Вы легко могли определить, к какому сайту относится конкретный файл.
$ sudo cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/site1.conf
Далее нам нужно отредактировать конфигурационный файл. Откроем его командой:
$ sudo nano /etc/apache2/sites-available/site1.conf
Приведем содержимое файла к следующему виду:
<VirtualHost *:80> ServerName site1.com DocumentRoot /var/www/site1/public_html <Directory /var/www/site1/public_html> AllowOverride All Require all granted </Directory> ErrorLog /var/www/site1/error.log CustomLog /var/www/site1/access.log combined </VirtualHost>
Поясним приведенные выше параметры.
Блок <VirtualHost> включает в себя набор директив, задающих настройки для конкретного виртуального хоста.
Имя этого хоста Вы указали в параметре ServerName — полное доменное имя Вашего сайта.
Далее следует директива DocumentRoot — она задает путь до директории, в которой хранятся файлы сайта site1 (все необходимые директории мы создадим позже).
Следующий параметр — блок <Directory>. Он задает настройки, которые будут применены для конкретной папки.
В данном случае:
- AllowOverride All — разрешение допускать настройки, заданные в .htaccess;
- Require all granted — доступ к каталогу разрешен всем.
В параметре ErrorLog мы указали расположение файла с логами ошибок.
В CustomLog — расположение файла с логами доступа.
После указания всех необходимых параметров закройте файл, сохранив изменения.
Далее мы создадим все необходимые папки, которые мы прописали в конфигурационном файле, и установим права на них:
$ sudo mkdir /var/www/site1/ $ sudo chown www-data:www-data /var/www/site1/ $ sudo mkdir /var/www/site1/public_html $ sudo chown www-data:www-data /var/www/site1/public_html
На этом этапе настройка виртуального хоста завершена, но желательно, конечно, проверить корректность его работы.
Для этого рекомендуем Вам создать index-файл в директории public_html:
$ nano /var/www/site1/public_html/index.html
Внесите в него любой самый простой html-код для проверки и сохраните документ.
Например:
<html> <head> <title>Удалось!</title> </head> <body> <h1>Виртуальный хост работает!</h1> </body> </html>
Далее включите сайт следующей командой:
$ sudo a2ensite site1
И выполните перезагрузку Apache:
$ sudo service apache2 restart
Теперь необходимо ввести в браузере адрес сайта, виртуальный хост для которого Вы настраивали. Если все работает, как нужно, на экране будет отражено содержимое созданного Вами индексного файла.
Надеемся, все получилось 
Установка Apache
Для того чтобы установить веб-сервер Apache, мы будем использовать менеджер пакетов Ubuntu apt:
$ sudo apt-get update $ sudo apt-get install apache2
После завершения установки введите в адресной строке браузера IP-адрес Вашего сервера. Если установка прошла успешно, Вы увидите стандартное приветственное окно Apache:
На этом же этапе можно установить дополнительные необходимые модули.
Например, если Вам в дальнейшем потребуются инструменты для анализа работы сервера, рекомендуем установить модуль utils — он содержит полезные утилиты для тестирования и администрирования сервера.
$ sudo apt-get install apache2-utils
Если Вам будет необходимо разделять права между пользователями, рекомендуем также установить модуль mpm-itk. При этом нужно будет настроить дополнительные параметры виртуальных хостов — информацию об этом Вы можете найти в открытых источниках сети.
В рамках данной инструкции мы не будем касаться установки и настройки данного модуля.
Для работы сервера с различными языками программирования (а также для расширения функционала сервера) можно установить библиотеки.
Если Ваш сайт использует PHP, необходимая библиотека устанавливается следующим образом:
$ sudo apt-get install libapache2-mod-php5
При использовании python полезно расширение libapache2-mod-wsgi;
при использовании Rails and Rack — libapache2-mod-passenger.
Установка происходит аналогичным образом — просто замените наименование библиотеки в команде.
Теперь перейдем к непосредственной настройке Apache.
Зачем нужен мультипроцессинг для веб-сервера?
Поскольку к веб-серверу одновременно может быть направлено множество запросов. То естественно, необходимо некоторую часть из них принять в обработку. А оставшиеся запросы поместить в очередь ожидания. После того, как занятый обработкой запроса процесс освободится. Он получит следующий, находившийся в очереди запрос. И так далее. Сколько должно одновременно обрабатываться запросов, сколько должно находиться в очереди, а также стратегия распределения задач между процессами — определяется системной конфигурацией веб-сервера. Эти параметры настраиваются в ходе оптимизации и тестирования программно-аппартной платформы. На которой предполагается работа веб-сервера. Исходя из прогнозируемых нагрузок и специфики выполняемых задач.
Но дело ещё и в том, чтобы не просто обеспечить максимальную производительность веб-сервера за счёт тонкой и сбалансированной настройки мультипроцессинговой обработки, но также обеспечить выполнение каждого процесса в «индивидуальном» порядке. Это подразумевает выполнение каждого процесса от имени конкретного пользователя. Такой подход обеспечивает максимальную безопасность без потери производительности. При условии, что имеют место достаточное количество аппаратных ресурсов. А также грамотная оптимизация работы соответствующего программного обеспечения (ПО).
Базовая настройка mpm-itk
Как уже говорилось ранее, для связывания виртуального хоста с конкретным пользователем в системе необходимо в конфигурационном файле хоста определить специальную директиву
Apache – AssignUserId user group: <IfModule mpm_itk_module> AssignUserId john john </IfModule>
Как можно видеть, директива AssignUserId определяет пользователя и группу (именно в таком порядке), указывая веб-серверу, что к данному виртуальному хосту может получить доступ процесс, принадлежащий только указанным пользователю и группе. В данном случае это пользователь john и его одноимённая группа.
Инструкция предназначена для задействования директивы AssignUserId только тогда, когда подключен соответствующий модуль, т. е. mpm-itk. Фраза «mpm_itk_module» формируется из двух составляющих: имени модуля, под которым он был подключен (в данном случае mpm_itk), а также классификатора объекта Apache – module, поскольку это подключаемый модуль. Просмотреть подключенные модули Apache (и их имена) можно в каталоге /etc/apache2/mods-enabled. А все доступные модули должны храниться в каталоге /etc/apache2/mods-available. Например, модулю mpm-itk соответствует файл mpm_itk.load.
Если теперь понаблюдать за процессами Apache, то можно убедиться, что во время обращения к пользовательскому виртуальному хосту (для которого определена директива AssignUserId) создаётся экземпляр Apache, запущенный от соответствующего пользователя.
