Mod_jk — это модуль или коннектор Apache, который соединяет контейнер сервлетов Apache Tomcat с веб-серверами, такими как Apache, IIS и другими. Mod_jk — это полная замена старого модуля mod_jser, который обрабатывает связь между Tomcat и HTTP-серверами с использованием протокола Apache JServ.
Мы не будем углубляться в работу модуля mod_jk, поскольку это выходит за рамки данной статьи. Вместо этого мы сосредоточимся на том, как интегрировать его с HTTP-сервером Apache.
В этой статье мы предполагаем, что у вас установлены и настроены серверы Apache Tomcat и Apache HTTPD. Если нет, просмотрите наши руководства по темам.
Шаг 1. Загрузите и установите mod_jk
Первым шагом является загрузка модуля mod_jk для Linux и его сборка для веб-сервера Apache. Если вы работаете в Windows, вы найдете предварительно созданный двоичный файл для настройки mod_jk.
Затем перейдите в извлеченный каталог /native как:
cd tomcat-connectors-1.2.48-src/native/
Находясь в собственном каталоге, выполните команду:
./configure -with-apxs=/usr/bin/apxs
Приведенная выше команда устанавливает путь к инструментам apxs для HTTP-сервера Apache. Если вы не знаете расположение инструментов apxs, используйте команду which как:
which apxs
/usr/bin/apxs
Если вы получили пустой результат, вам необходимо установить пакет apache dev с помощью команды:
sudo apt install apache2-dev
# или
yum install httpd-devel
Следующим шагом является создание системного объектного файла для модуля mod_jk.
Используйте команду make в собственном каталоге.
make
После успешного завершения вы должны увидеть каталог apache-2.0, созданный в собственном каталоге.
Вы должны увидеть в каталоге файл mod_jk.so.
Скопируйте файл mod_jk.so в каталог модулей apache. Он должен находиться в /usr/lib/apache2/modules или /etc/httpd/modules.
sudo cp mod_jk.so /usr/lib/apache2/modules/
Шаг 2: Загрузите модуль mod_jk
После того, как мы добавили модуль mod_jk в каталог модулей Apache HTTPD, нам нужно загрузить его, отредактировав файл httpd.conf.
Как системный администратор, вам необходимо понимать, что происходит под капотом различных служб в вашей системе. Ведение журнала, вероятно, лучший способ сделать это.
Журналы позволяют собирать информацию о службах и приложениях, запущенных в вашей системе, и сохранять этот журнал в файл для использования в будущем.
Из этой статьи вы узнаете, как собрать подробную информацию о службе Apache Tomcat, включив режим DEBUG.
Примечание
В этой статье мы не рассматриваем установку Apache Tomcat. Ознакомьтесь с нашими руководствами по этой теме, чтобы узнать больше.
Как включить ведение журнала отладки Apache Tomcat в Linux
Чтобы включить ведение журнала отладки для Apache Tomcat в Linux, отредактируйте файл logging.properties. Файл находится в каталоге conf корневой установки Apache Tomcat.
Например:
vim /opt/tomcat/conf/logging.properties.
Найдите следующую запись:
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = FINE
Измените значение с FINE на ALL.
Последняя запись должна быть:
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = ALL
Сохраните файл и закройте. Вам нужно будет перезапустить Tomcat Service, чтобы включить уровни журнала.
Если вам не нужны все сообщения журнала от Tomcat, вы можете установить различные уровни, используя уровни журнала JULI, как:
SEVERE — Сообщения о серьезных сбоях
WARNING — возможные ошибки
INFO — Информационные журналы
FINE — Журналы трассировки
CONFIG — статические журналы конфигурации
FINEST — подробные журналы трассировки
FINER — подробные журналы трассировки
ALL — все сообщения (режим отладки)
Вы также можете включить ведение журнала для внутренних компонентов Apache Tomcat, изменив следующие значения на all:
Как включить журнал отладки Apache Tomcat в Windows
Предположим, вы запускаете Apache Tomcat на машине с Windows. Вы можете использовать предоставленный интерфейс конфигурации для управления уровнями журнала.
Откройте меню «Пуск» и найдите «Настроить Tomcat».
Запустите приложение и перейдите на вкладку ведения журнала. Выберите уровень журнала и установите его на DEBUG.
Затем нажмите «Применить» и перейдите на вкладку «Общие». Наконец, нажмите «Остановить», а затем «Пуск», чтобы перезапустить службу Apache.
Заключение
В этой статье показано, как включить ведение журнала отладки для Apache Tomcat в системах Windows и Linux.
Очень часто при администрировании веб-сервера Apache возникает необходимость настройки режимов обработки адресов URL. Например необходимо, чтобы запросы автоматически перенаправлялись с одного адреса на другой. Также, если нужно, чтобы веб-приложения работали на «чистых» ссылках, то для этого также необходима настройка модуля mod_rewrite. В данной статье на простых примерах будут рассмотрены базовые приёмы обработки перезаписи URL, реализуемой модулем mod_rewrite, на основе которых можно легко построить свои собственные правила и режимы обработки ссылок.
Включение модуля mod_rewrite и управление его работой
Обычно модуль mod_rewrite уже имеется в базовой поставке Apache и устанавливать его дополнительно не нужно. Остаётся его только включить. Например, для Ubuntu:
$ sudo a2enmod rewrite
Управление работой самого модуля mod_rewrite осуществляется при помощи файла .htaccess. Этот файл предназначен для активации и задействования директив веб-сервера Apache индивидуально для каждого из виртуальных хостов (или доменов).
Итак, для начала необходимо удостовериться, что Apache разрешает обработку файлов .htaccess. В конфигурационном файле Apache /etc/apache2/apache2.conf директива AllowOverride должна иметь значение All в блоке:
Options Indexes FollowSymLinks
AllowOverride All
Require all granted
Следует заметить, что вместо «/var/www/html» может быть указан и другой каталог, в зависимости от того, как и где настроено расположение корневого каталога виртуальных хостов Apache. Также необходимо проверить, что в файле /etc/sites-enabled/000-default.conf не содержится лишних директив (а лучше их убрать) AllowOverride, противоречащих тем, что установлены в файле apache2.conf. После сохранения всех изменений необходимо перезапустить веб-сервер:
$ sudo systemctl restart apache2
Далее, в начало файла .htaccess нужно добавить директиву:
RewriteEngine on
Она указывает, что Apache должен использовать модуль mod_rewrite для обработки условий и правил перезаписи URL.
Файл .htaccess может быть создан, как уже отмечалось, отдельно для каждого из виртуальных хостов. Обычно его помещают в корневой каталог, в котором находятся файлы требуемого виртуального хоста. В данном руководстве для расположения файла .htaccess будет использоваться каталог /var/www/html/ для глобальной обработки URL на веб-сервере.
Пример создания простой страницы и перезаписи URL для неё
Для демонстрации работы модуля mod_rewrite по перезаписи URL страницы, можно эту самую страницу создать (в самом простом варианте) и применить к ней (точнее, к её адресу) простой шаблон перезаписи.
Итак, нужно создать файл HTML-страницы hello.html, которая будет размещаться в каталоге /var/www/html/hello.html со следующим содержимым:
Эта страница будет доступна по адресу ip_server/hello.html. Здесь «ip_server»– это IP-адрес сервера, на котором работает Apache. Вместо IP-адреса также можно использовать и доменное имя при должных настройках.
Особенность в том, что эта страница доступна только если вводить адрес, содержащий «hello.html». Любое другое написание, например «hello» приведёт к ошибке 404 — нет такого документа. Чтобы иметь возможность получать доступ к странице hello.html по «hello» нужно всего лишь настроить перезапись адреса. Редактирование файла .htaccess:
$ sudo nano /var/www/html/.htaccess
После ранее добавленной строки «RewriteEngine on» нужно добавить следующую:
RewriteRule ^hello$ hello.html [NC]
Только после этих изменений в веб-браузере по адресу ip_server/hello страница hello.html будет доступна.
Синтаксис добавленной записи следующий:
^hello$ — это шаблон подстановки, который должен совпадать с частью URL, вводимого в веб-браузере. Здесь символ (^) обозначает начало фразы шаблона, а символ ($) — его окончание;
hello.html – это действительный путь к исходной странице hello.html;
В результате, теперь страница hello.html будет доступна по следующим адресам: ip_server/hello, ip_server/Hello и ip_server/hello.html.
Таким образом и происходит перезапись URL модулем mod_rewrite по инструкциям из .htaccess.
Применение общих шаблонов перезаписи
Выражения в файле .htaccess, применённые в предыдущей главе — это ничто иное, как правила перезаписи. В общем виде они имеют следующий синтаксис:
RewriteRule pattern substitution [flags]
Здесь RewriteRule – это, собственно, сама директива, pattern – шаблон, задаваемый регулярным выражением. Он предназначен для поиска подстроки. Далее, substitution – это целевой действительный URL. А flags – флаги опций, которые задают определённое специфическое поведение правил.
Самым наглядным и общим примером является перезапись (точнее, упрощение) строки дополнительного запроса. Они используются веб-приложениями для передачи параметров скриптам, по которым нужно получить соответствующий результат. Строки запроса начинаются с символа «?» и заканчиваются символом «&». Например:
В результате подстрока URL «results.php?item=shoes&season=summer» будет переписываться строкой «shoes/summer».
Второй случай используется, когда нужно оптимизировать используемое правило так, чтобы оно являлось универсальным для разных строк запросов, т. е. с разными параметрами. Для данного примера пусть требуется, чтобы правило обрабатывало строку запросов для нескольких сезонов, а не только для «summer». Для этого нужно сначала определить набор самих параметров, которые должны разделяться символом вертикальной черты «|». После этого можно в регулярном выражении ссылаться на эту группу параметров, используя переменную $1, где «1» — это номер набора. Например:
Сопоставление набора символов используется обычно, когда нужно, чтобы пользователи могли открывать чистые ссылки любых других разделов сайта, а не только «shoes», как в данном примере. Для этого нужно:
составить регулярное выражение, определяющее все буквенные и цифровые символы, которые могут повторяться неограниченное число раз. Такое выражение заключается в квадратные скобки, объединяемыми знаком плюса «+»;
это выражение нужно заключить в группу (в круглые скобки) и присвоить его переменной $2 – группа №2.
Если задать определённое условие с помощью директивы RewriteCond, то если оно выполняется, Apache запустит выполнение правила, следующего сразу за этим условием. Синтаксис RewriteCond следующий:
RewriteCond tststr condition [flags]
Здесь tststr – строка, с которой сравнивается условие. А condition – шаблон, с которым сравнивается строка, заданная в tststr. Дополнительные параметры задаются с помощью флагов flags.
В качестве примера можно создать условие, при котором все запросы к несуществующим страница будут перенаправляться например, на домашнюю страницу:
Здесь выражение %{REQUEST_FILENAME} выполняет проверку строки запроса. Далее, оператор (!), означающий условие «не», предписывает, что отсутствие требуемого в запросе файла (-f) должно указывать Apache запускать в обработку следующее за этим условием правило перенаправления. Далее выполняется само правило переадресации, которое перенаправляет все запросы на страницу /admin/home.
Пример блокировки всего трафика, кроме поступающего с определённого IP-адреса:
Здесь флаг «F» запрещает доступ, а флаг «L» – указывает, что данное правило должно выполниться последним.
Для обратного эффекта, т. е. для разрешения запросов с любых IP-адресов кроме 12.38.57.123 нужно перед регулярным выражением записи IP-адреса в определении условия убрать оператор «не» — символ восклицательного знака (!):
в заключении стоит ещё раз отметить, что были рассмотрены только самые базовые приёмы управления модулем mod_rewrite для веб-сервера Apache. Для более подробного и глубокого освоения написания правили задания условий следует хорошо знать и составлять как регулярные выражения, так и назначение ключевых слов и дополнительных директив
Apache.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Многие говорят, что веб-сервер Apache не обладает достаточной производительностью. Однако, это абсолютно не соответствует действительности. Данное мнение сложилось вследствие искажения оценки объективной особенности Apache – его работу и производительность необходимо скрупулёзно оптимизировать, что не так-то и просто. На самом деле Apache – это очень мощный и очень производительный веб-сервер. Да к тому же ещё так легко масштабируется и адаптируется к различным условиям применения. Однако, это всё в совокупности и является тормозящим фактором, сильно влияющим на производительность. В данной статье речь пойдёт о том, каким образом правильно и эффективно оптимизировать работу и производительность Apache без ущерба выбранной функциональности. Предлагаемые методы являются универсальными, допускается лишь незначительные различия в их реализации, в зависимости от используемой системы Linux.
Отключение неиспользуемых функций и модулей
По-умолчанию практически во всех популярных дистрибутивах Apache поставляется в универсальной комплектации, т. е. снабжён большим набором модулей. Это позволяет использовать его практически для любых веб-приложений.
Однако, если наблюдается недостаточная производительность или слишком большое потребление аппаратных ресурсов (как например памяти), следует выяснить, какие модули Apache для текущей конфигурации никогда не используются и даже не актуальны. Например, для современных, даже самых требовательных веб-приложений требуется не более 10-12 модулей. Не говоря уже о среднестатистических сайтах на WordPress или Drupal.
В данном случае определение и отключение ненужных модулей определяется в соответствии с требованиями для используемых веб-приложений, которые всегда заранее известны. Например, эти требования предоставляются самими разработчиками веб-приложений и доступны в открытом доступе. Также необходимо учитывать, что отключение модуля, который был определён как «неиспользуемый» явно, может негативно повлиять на работу других — «нужных» модулей, поскольку некоторые модули связаны между собой зависимостями. Поэтому при принятии решения об отключении тех или иных модулей необходимо отслеживать их зависимости. Эту информацию легко получить из официальной документации модуля, либо экспериментально. Во втором случае после отключения модуля и перезапуска Apache будет получена ошибка, как например:
Syntax error on line 6 of /etc/apache2/sites-enabled/site-company1:
Invalid command ‘DAVLock’, perhaps misspelled or defined by a module not included in server configuration
Action ‘configtest’ failed
В данном случае Apache использует модуль, который, в свою очередь, не может задействовать функционал, предоставляемый модулем dav_fs, который был отключен.
В Debian-системах, таких как Ubuntu, модули Apache хранятся в каталоге /etc/apache2/mods-available, а список включенных модулей — в каталоге /etc/apache2/mods-enabled. Отключение модуля выполняется путём удаления соответствующего файла в каталоге mods-enabled, либо можно использовать команду:
$ sudo a2dismod mpm_itk
Аналогичным образом работает и команда включения модулей — a2enmod.
Самыми «прожорливыми» модулями Apache, потребляющими довольно много ресурсов системы являются: Rewrite, SSL, Phyton, PHP, Perl. Если они не используются, то конечно, их следует отключать. Либо заменять другими менее требовательными аналогами. Например, модуль Rewrite можно в большинстве случаев заменить модулем Alias.
Оптимизация обслуживания HTTP-запросов
Различные сайты написаны на различных языках программирования. Соответственно, для обслуживания HTTP-запросов к ним и их полноценной работы Apache использует интерпретаторы языков. Взаимодействие веб-сервера и интерпретатора обеспечивается соответствующими модулями. Для PHP это mod_php, а для Ruby – mod_rails. Это «стандартные» модули, предоставляемые базовой поставкой Apache. Однако, они разработаны только с учётом обеспечения дополнительной функциональности без каких-либо решений по оптимизации производительности и потребления ресурсов.
Так, например, модуль mod_php способен потреблять около 100 Мб RAM для работы всего одного процесса, обслуживающего как минимум один HTTP-запрос. Следовательно, чем больше запросов, тем больше потребляемая память только от одного PHP-модуля. В данной ситуации в качестве альтернативы, но уже с куда более оптимизированными производительностью и потреблением памяти существует модуль php-fpm. Этот модуль позволяет обрабатывать HTTP-запросы к веб-приложениям, написанным на PHP, используя технологию Fast CGI. Аналогичными решениями являются uWSGI для Python и Unicorn для Ruby.
Дело в том, что при использовании модуля php-fpm и ему подобных, изначально в памяти создаётся постоянный процесс для интерпретатора PHP ( Python или Ruby). И только после этого происходит перенаправление запросов от Apache к этому процессу для дальнейшей обработки. Таким образом, динамический контент обрабатывается всего двумя процессами. При этом потребление памяти может снизиться более чем в 8 раз.
Ограничение максимального количества процессов Apache
Как было показано выше, один дочерний процесс Apache может использовать 100 Мб RAM и выше. Когда таких процессов слишком много, память системы быстро будет исчерпана и веб-сервер начнёт «тормозить». В конфигурации по-умолчанию для Apache зарезервировано определённое количество процессов, например 30. Для не самого мощного сервера это может быть слишком много. Вообще этот параметр всегда важно тщательно подбирать для конкретной системы.
Для начала важно выяснить, сколько памяти требуется (с небольшим запасом) для корректной и стабильной работы веб-приложения. Затем нужно выделить большую часть свободной памяти веб-серверу. Ситуацию с памятью можно отследить, используя команду top, например:
top -bn 1
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
...
15015 www-data 20 0 232m 9644 1900 S 0.0 1.6 0:00.02 apache2
15016 www-data 20 0 232m 9644 1900 S 0.0 1.6 0:00.01 apache2
15017 www-data 20 0 232m 9644 1900 S 0.0 1.6 0:00.02 apache2
Как можно видеть, в системе запущено 3 процесса Apache почти по 10 Мб (столбец RES) каждый. Ели этого много для используемой конфигурации, то целесообразно уменьшить количество процессов для одновременно обрабатываемых запросов. Это делается путём изменения соответствующего параметра (или параметров) работы мультипроцессингового модуля Apache – по-умолчанию это mpm_prefork. В системах Ubuntu соответствующий конфигурационный файл находится в /etc/apache2/mods-available и называется mpm_prefork.conf. Нужно изменить значение параметра MaxClients в соответствии с расчитанным значением объёма RAM, которое можно выделить Apache для данной системы. Например, по-умолчанию это значение обычно 25 — 30. Для не самого мощного сервера можно уменьшить до 15 (и даже меньше):
Теперь нужно перезагрузить Apache, чтобы сделанные настройки вступили в силу. Конечно, когда количество клиентов достигнет максимального количества, то пользователь просто получит ошибку сервера. Однако, он всегда может перезагрузить страницу и снова получить доступ к серверу (веб-приложению). Поскольку ограничение обслуживающих процессов не позволяет превысить лимит памяти, отведённой Apache, то это никак не скажется на его производительности. Ведь памяти всегда хватает. Это не совсем «демократично» по отношению к пользователям. Однако это лучше, чем бесконечно поддерживать «тормозящие» или полузависшие процессы Apache.
Использование альтернативных мультипроцессинговых модулей
Здесь нет чётких рекомендаций относительно того, кокой именно мультипроцессинговый модуль и для какой конфигурации использовать. Одни из них экономят процессорное время, другие — использование RAM.
Например, по-умолчанию Apache использует универсальный модуль mpm-prefork. Который работает практически со всеми интерпретаторами (PHP, Ruby и т. д.). Однако в качестве альтернативы можно использовать модуль mpm-worker. Который обладает более производительной стратегией управления дочерними процессами. Но данный модуль не поддерживает работу с интерпретаторами PHP и Ruby через стандартные внешние модули, такие как mod-php. Поэтому выбор мультипроцессингового модуля Apache – это очень выверенное и обдуманное решение.
Заключение
В заключение стоит ещё раз подчеркнуть, что веб-сервер Apache, вопреки устоявшемуся мнению, на самом деле очень мощная, универсальная и высокопроизводительная система с огромным потенциалом. Однако, его раскрытие напрямую зависит от грамотной и тонкой настройки и оптимизации всех компонентов веб-сервера.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
В целях безопасности, в частности во избежание перехвата конфиденциальных, персональных или важных данных. Многие владельцы сайтов в сети защищают трафик с помощью SSL-сертификатов. Естественно, защите подлежит только тот трафик, который связан непосредственно с запросами и передачей данных с определённым адресом — адресом сайта. Системные администраторы, сотрудники техподдержки должны ориентироваться в вопросах, касающихся создания и внедрения SSL-сертификатов для хостов. Поскольку предоставляют соответствующие услуги. Для этих целей в системах Linux существует утилита openssl. Она является свободной реализацией методов защиты, протокола SSL, а также генерации сертификатов.
Как SSL-сертификат помогает защитить данные?
На самом деле схема защиты трафика основана на его шифровании открытым ключом и его расшифровке закрытым ключом. Понятие SSL-сертификата применимо в контексте подтверждения того факта, что открытый ключ действительно принадлежит именно тому домену, с которым происходит соединение. Таким образом, в данной схеме присутствуют две составляющие:
Пара ключей (открытый и закрытый) — для шифрования/расшифровки трафика;
Подпись открытого ключа. Гарантирующая, что он подлинный и обслуживает именно тот домен, для которого и был создан.
Обе эти составляющие и представляют собой то, что принято обозначать понятием SSL-сертификат. Подпись является гарантией, поскольку выдаётся авторитетным центрами сертификации. Это доступные всем онлайн-сервисы (достаточно воспользоваться любой поисковой системой), которым можно отправить свой ключ, заполнив соответствующую анкету. Далее сервис (центр сертификации) обрабатывает данные из анкеты и сам ключ и высылает уже подписанный ключ обратно его владельцу. Среди самых популярных на сегодняшний день центров сертификации являются такие как Comodo.
Важно заметить, что зашифрованный открытым ключом трафик возможно расшифровать только соответствующим ему закрытым ключом. В свою очередь подпись для открытого ключа от авторитетного цента говорит, что зашифрованный трафик пришёл от «своего» или подлинного узла и его можно принять в обработку, т. е. расшифровать закрытым ключом.
Общий порядок создания SSL-сертификата, ключи и подпись
Во время создания SSL-сертификата происходит последовательная обработка следующих видов ключей:
*.key – это сами ключи шифрования, открытий и/или закрытый;
*.csr – ключ, содержащий сформированный запрос для получения подписи сертификата от центра сертификации, а сам запрос — это открытый ключ и информация о домене и организации, связанной с ним;
*.crt, *.cer, *.pem – это, собственно, сам сертификат, подписанный центром сертификации по запросу из файла *.csr.
Для начала нужно создать закрытый ключ:
$ openssl genrsa -des3 -out server.key 2048
Здесь команда genrsa генерирует RSA-ключ, опция -des3 указывает алгоритм шифрования ключа. А опция -out указывает, что ключ должен быть получен в виде файла server.key. Число 2048 — это сложность шифрования. При выполнении этой команды пользователю будет предложено ввести пароль для шифрования. Поскольку указан его алгоритм опцией -des3. Если это личный ключ и его планируется использовать на сервере, который можно настроить в собственных целях, то естественно шифрование обязательно. Однако, многие серверы требуют закрытые ключи без шифрования (например хостинг-площадки, поскольку предоставляют универсальную услугу по заказу SSL-сертификатов). Поэтому перед генерацией закрытого ключа нужно определиться, как он будет использоваться.
Теперь нужно создать запрос на подпись — CSR-файл, который будет включать только что сгенерированный ключ server.key:
При выполнении этой команды пользователю необходимо ввести информацию о домене и организации. Причём наименование домена следует вводить точно, например, если идентификатор URL сайта https://mycompany.com, то ввести нужно mycompany.com. Для URL-идентификатора www.mycompany.com уже необходим отдельный сертификат.
Теперь файл server.csr со сформированным запросом на подпись можно отправить в выбранный центр сертификации.
Подписание SSL-сертификатов
Получить подписанный сертификат, когда имеется закрытый ключ и запрос на подпись можно несколькими способами: воспользоваться услугой авторитетных центров сертификации, отправив им запрос (CSR-файл) и получив в ответ готовый сертификат *.crt. Либо можно сделать сертификат самоподписанным. Т. е. подписать его тем же ключом, который использовался при создании файла CSR. Для этого следует выполнить команду:
Здесь опция -days указывает количество дней, в течение которых выпускаемый сертификат server.crt будет действителен. В данном случае на протяжении одного года.
Также можно создать самоподписанный сертификат из имеющегося закрытого ключа без использования CSR-файла. Но в этом случае нужно вводить информацию CSR-запроса:
Параметр -x509 задаёт формат генерируемого сертификата. Он является самым распространённым и используется в большинстве случаев. Опция -new позволяет запрашивать информацию для запроса у пользователя.
Важно отметить, что сертификаты, подписанные авторитетными центрами сертификации известны веб-браузерам. Самоподписанные сертификаты необходимо импортировать в хранилище доверенных сертификатов веб-браузера вручную. Поскольку соединения с доменами, обслуживаемыми такими сертификатами по-умолчанию блокируются.
Использование SSL-сертификатов для домена
Для использования сертификата доменом, для которого он был создан, необходимо соответствующим образом настроить виртуальный хост этого домена. Для начала нужно сохранить файлы *.crt и *.key где-нибудь, где доступ к ним может получить только их владелец. Например в ~/ssl/certs/ нужно поместить файл server.crt, в ~/ssl/private/ — файл server.key. Далее, в конфигурационном файле виртуального хоста нужно определить следующие директивы:
Важно заметить, что для SSL-соединений домена должен быть отдельный конфигурационный файл (или просто отдельная конфигурация в одном файле) виртуального хоста для него. Это необходимо, поскольку обычные HTTP-соединения обрабатываются по порту 80, а HTTPS (SSL) — по 443. Это отдельные конфигурации одного виртуального хоста (хотя это не совсем верное определение). Также для Apache должен быть включен модуль SSL. Типичная конфигурация может выглядеть следующим образом:
Как подключить ssl сертификата в nginx читайте в этой статье.
Заключение
В заключение следует заметить, что генерация и подключение SSL-сертификатов к домену — далеко не самая сложная задача. Однако она требует очень внимательного выполнения отдельных её этапов, поскольку от ошибки зависит безопасность для домена.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Веб-серевер Apache является универсальным решением для обслуживания HTTP-запросов и обработки веб-контента. Практически для всех дистрибутивов Linux он поставляется готовым не просто для базового использования, но и позволяет организовать полноценный хостинг как минимум для ведения разработки веб-приложений. Однако, Apache всегда отличался тем, что для наиболее полного раскрытия его возможностей и потенциала он требует довольно щепетильного конфигурирования и оптимизации. Это является одновременно и недостатком и плюсом. Поскольку только таким образом можно добиться от Apache максимальной эффективности для любой специфики задач. По этой же причине (сложность настройки и оптимизации) был разработан высокопроизводительный «из коробки» веб-сервер NGINX. Ещё одним плюсом Apache является поддержка подключаемых модулей. Что делает его легко масштабируемым и позволяет адаптировать под различные задачи. Самих же модулей Apache существует огромное количество. А свободная архитектура и подробная документация позволяют разрабатывать свои собственные модули.
Зачем нужны модули Apache
Разработчики Apache вряд ли могут предусмотреть все потребности, возникающие в процессе развития веб-технологий. В такой ситуации рационально осуществлять поддержку расширения функционала с помощью отдельных подключаемых программных компонентов — модулей. Каждый модуль добавляет к базовому или текущему функционалу веб-сервера новые возможности. Таким образом, модули Apache позволяют легко оснащать его необходимыми возможностями. В то же время, если отпадает необходимость в использовании какого-либо модуля — его легко отключить. Экономя на потребляемых ресурсах.
Такой подход удобен также и тем, что модули можно (и легко) разрабатывать отдельно. Без затрагивания основного кода ядра Apache.
Как работает механизм подключения модулей?
Модули Apache представляют собой программное обеспечение (ПО) в виде динамически подключаемых библиотек — файлов с расширением *.so. Хранятся эти модули (т. е. библиотеки *.so) обычно там же, где и все библиотеки систем Linux – в каталоге /usr/lib. В котором конкретно для модулей Apache предусмотрен подкаталог apache/modules.
Установка же модуля подразумевает подключение файла библиотеки (модуль *.so) к конфигурации Apache. Чтобы он мог использовать функции, реализованные и содержащиеся в файле модуля. Подключение происходит при помощи специальных инструкций в виде директив конфигурации. Эти инструкции содержатся в конфигурационных файлах *.load и *.conf. Которые подключают модуль и определяют конфигурацию его работы соответственно.
Чтобы Apache «знал», что нужно подключить модуль, его конфигурационные файлы (модуля) должны быть в специальном каталоге /etc/apache2/mods-available. А для того, чтобы Apache «знал», как именно подключить модуль. В специальном каталоге /etc/apache2/mods-enabled должны существовать символические ссылки на соответствующие конфигурационные файлы из каталога /etc/apache2/mods-available. Наличие такой ссылки и позволяет Apache подключать дополнительные функции библиотек «из вне». При условии, что они совместимы и корректно задана конфигурация подключения.
Подобная схема подключения по принципу раздельного хранения файлов библиотек модулей, их конфигурационных файлов и связывания их символическими ссылками позволяет легко ориентироваться в конфигурации и управлять ей. Фактически подключение модулей осуществляется на уровне файловой системы (ФС). Которая представляет собой унифицированный интерфейс для этого.
Включение и отключение модулей
Подавляющее большинство модулей Apache поставляются в стандартных репозиториях практически любого дистрибутива Linux. Для их установки и подключения нужно просто воспользоваться системой управления пакетами (СУП) дистрибутива. Например, в Ubuntu для установки модуля FastCGI следует выполнить следующую команду:
$ sudo apt install libapache2-mod-fcgid
Сами модули нетрудно отыскать в репозиториях по ключевым словам, например для СУП APT в Ubuntu это выглядит так:
apt-cache search fcgi
apache2-utils - Apache HTTP Server (utility programs for web servers)
libcgi-fast-perl - CGI subclass for work with FCGI
libfcgi-perl - helper module for FastCGI
python-paste - tools for using a Web Server Gateway Interface stack - Python 2.x
python-paste-doc - tools for using a Web Server Gateway Interface stack - documentation
python3-paste - tools for using a Web Server Gateway Interface stack - Python 3.x
chiark-utils-bin - chiark system administration utilities
fcgiwrap - simple server to run CGI applications over FastCGI
libanyevent-fcgi-perl - Perl non-blocking FastCGI server
libapache2-mod-fcgid - FastCGI interface module for Apache 2
libapache2-mod-fcgid-dbg - debugging symbols for mod_fcgid
В данном выводе пакет libapache2-mod-fcgid, как следует из его описания, и является искомым вариантом. После установки модуля нужно перезапустить Apache.
Но когда использование СУП или менеджера пакетов для установки не представляется возможным, например, когда разрабатывается собственный модуль, то необходимо выполнить вручную порядок действий, соответствующий механизму подключения, описанному в предыдущей главе:
скопировать файл библиотеки модуля в /usr/lib/apache/modules;
создать конфигурационный файл module_name.load в каталоге /etc/apache2/mods-available;
в каталоге /etc/apache2/mods-enabled создать символическую ссылку на файл module_name.load из каталога /etc/apache2/mods-available;
перезапустить веб-сервер Apache, либо перезагрузить его конфигурацию.
Содержимое файла конфигурации module_name.load (имя задано условно) представляет собой, как уже было отмечено, определение директивы загрузки функций из файла библиотеки модуля (условно name_module.so) по соответствующему пути:
Во время запуска (или перезагрузки конфигурации) Apache «просматривает» каталог /etc/apache2/mods-enabled, и по имеющимся в нём символическим ссылкам читает соответствующие файлы конфигурации из каталога /etc/apache2/mods-available. Содержащаяся в них директива LoadModule указывает Apache загрузить соответствующий модуль в свое адресное пространство.
Очевидно, что для отключения модулей нужно просто удалить соответствующую символическую ссылку в каталоге mods-enabled, а также перезапустить веб-сервер.
В некоторых дистрибутивах для удобства управления модулями и вообще конфигурацией Apache предоставляются утилиты, например из пакета apache2-utils. Этот пакет предоставляет команды, позволяющие быстро подключать и отключать модули: a2enmod и a2dismod соответственно. Например:
$ sudo a2enmodule mpm_itk
Эта команда включит модуль mpm-itk. При этом библиотека модуля и соответствующий конфигурационный файл mpm_itk.load уже должны присутствовать в системе.
В заключение необходимо отметить, что на примере установки дополнительных модулей Apache видно, что этот процесс далеко не самый быстрый и простой. Однако все действия абсолютно логичны, а потому легко усваиваются, избавляя от необходимости что-то запоминать или часто обращаться к справочным руководствам.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.