Тюнинг веб-сервера
PHP
Открываем на редактирование следующий файл:
vi /etc/php.ini
И правим следующее:
upload_max_filesize = 512M
…
post_max_size = 512M
…
short_open_tag = On
…
date.timezone = «Europe/Moscow»
Перезапускаем php-fpm и httpd:
systemctl restart php-fpm
systemctl restart httpd
NGINX
Открываем на редактирование следующий файл:
vi /etc/nginx/nginx.conf
И внутри секции http добавляем:
client_max_body_size 512M;
После перезапускаем nginx:
systemctl restart nginx
Подробнее про тюнинг NGINX в статье Практические советы по тюнингу веб-сервера NGINX.
Postfix
Чтобы отправляемая почта меньше попадала в СПАМ, необходимо выполнить следующие шаги:
- Прописать PTR-запись.
- Создать запись SPF.
- Настроить DKIM.
Конфигурации виртуальных хостов
Стандартный виртуальный хост находится в файле default в каталоге sites-available.
Чтобы ознакомиться с общим форматом виртуального хоста, откройте этот файл:
По умолчанию виртуальный хост обрабатывает запросы на порте 80.
Это не означает, что веб-сервер обязательно будет обрабатывать каждый запрос через этот порт. Apache может переопределять конфигурации.
Настройки виртуального хоста высшего уровня
Эти параметры устанавливаются в разделе Virtual Host и применяются ко всему виртуальному хосту.
Директива ServerName задаёт доменное имя или IP-адрес сервера. Это индивидуальный параметр каждого виртуального хоста, который может переопределить настройки по умолчанию, если он совпадает со значением ServerName.
Параметр ServerAlias позволяет добавить алиасы сайта – альтернативные имена и пути, ведущие к одному контенту. Так, например, часто устанавливается алиас домена с www.
DocumentRoot задаёт каталог, в котором веб-сервер хранит контент данного виртуального хоста. В Ubuntu для этого по умолчанию используется /var/www.
В конфигурации виртуального хоста есть специальный раздел для настройки обработки отдельных каталогов файловой системы. Эти настройки также можно переопределять.
Сначала виртуальный хост предлагает набор правил для каталога / (root-каталог). Этот раздел обеспечит базовую конфигурацию виртуального хоста, поскольку он относится ко всем файлам, которые обслуживаются в файловой системе.
По умолчанию Ubuntu не накладывает никаких ограничений на файловую систему. Apache рекомендует добавить несколько стандартных ограничений доступа, например:
Это заблокирует доступ ко всему контенту, если в последующих определениях каталогов не указано иное.
Далее идут настройки каталога document root, в которых параметр allow from all переопределяет параметры каталога /.
Параметр AllowOverride позволяет настроить переопределение конфигураций с помощью файлов .htaccess. Чтобы переопределить настройки, файл .htaccess должен находиться в каталоге с контентом. По умолчанию эта функция отключена.
Настройки Alias и ScriptAlias
Иногда перед разделом Directory идут параметры Alias и ScriptAlias.
Директива Alias позволяет добавлять к обслуживаемому контенту каталоги вне DocumentRoot.
ScriptAlias работает аналогичным образом, но содержит путь к каталогам с исполняемыми файлами.
К примеру, такая строка в виртуальном хосте для сайта example.com откроет доступ к контенту в каталоге /path/to/content/ при запросе example.com/content/.
Помните, что открывая доступ к дополнительным каталогам, нужно устанавливать ограниченные привилегии на них.
Включение сайтов и модулей в Apache
Создав файл виртуального хоста, вы можете включить его. Для этого нужно создать символическую ссылку на файл в каталоге sites-enabled:
Включив сайт, перезапустите Apache, чтобы веб-сервер перечитал конфигурации:
Чтобы отключить виртуальный хост, нужно удалить символьную ссылку из sites-enabled:
После этого нужно снова перезапустить веб-сервер:
Включить и отключить модуль Apache можно с помощью следующих команд (соответственно):
Они работают так же, как и ранее упомянутые команды a2ensite иa2dissite. После включения или отключения модуля нужно перезапускать веб-сервер.
Установка PHP и PHP-FPM
Устанавливаем PHP и PHP-FPM:
apt-get install php php-fpm
Разрешаем автозапуск php-fpm и запускаем его:
systemctl enable php7.4-fpm
* обратите внимание, что мы запустили php-fpm версии 7.4. Но установлена может быть и другая версия — ее можно узнать по версии php командой php -v
Настройка связки NGINX + PHP
Открываем файл для настройки виртуального домена по умолчанию:
vi /etc/nginx/sites-enabled/default
В секции location или server редактируем параметр index на следующее значение:
…
index index.php index.html index.htm;
…
* в данном случае мы сказали серверу сначала искать индексный файл index.php, затем остальные по списку.
А внутри секции server добавим следующее:
location ~ \.php$ {
set $root_path /var/www/html;
fastcgi_pass unix:/run/php/php7.4-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;
include fastcgi_params;
fastcgi_param DOCUMENT_ROOT $root_path;
}
* где /var/www/html — корневой путь хранения скриптов; /run/php/php7.4-fpm.sock — путь до сокетного файла для взаимодействия с php-fpm
Обратите еще раз внимание, что если в нашей системе будет установлена другая версия php, необходимо внести соответствующую корректировку
Пример файла default:
server {
listen 80 default_server;
listen :80 default_server;
root /var/www/html;
index index.php index.html index.htm index.nginx-debian.html;
server_name _;
location / {
index index.php index.html index.htm;
}
location ~ \.php$ {
set $root_path /var/www/html;
fastcgi_pass unix:/run/php/php7.4-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;
include fastcgi_params;
fastcgi_param DOCUMENT_ROOT $root_path;
}
}
Проверяем правильность настроек nginx:
nginx -t
И перезагружаем его:
systemctl restart nginx
Открываем конфигурационный файл PHP-FPM:
vi /etc/php/7.4/fpm/pool.d/www.conf
Проверяем, что путь до сокетного файла такой же, как мы задали в настройках NGINX:
listen = /run/php/php7.4-fpm.sock
В противном случае меняем его и перезапускаем сервис:
systemctl restart php7.4-fpm
Теперь заходим в каталог хранения настроенного сайта:
cd /var/www/html
Создаем index.php со следующим содержимым:
vi index.php
<?php phpinfo(); ?>
Открываем браузере и переходим по адресу http://<IP-адрес сервера>. Мы должны увидеть сводную информацию по PHP и его настройкам:
* в данном примере используется php версии 7.4.
Настройка SELinux для web сервера apache
Раздел для тех, кто хочет настроить SELinux на своем web сервере. Сначала ставим пакет policycoreutils-python-utils если он еще не установлен. Он нам нужен для утилиты semanage.
# dnf install policycoreutils-python-utils
Теперь автоматически сформируем модуль для selinux на основе событий аудита, которые накопились, пока мы настраивали сайт. Посмотреть их можно командой.
# grep httpd /var/log/audit/audit.log | audit2why
Создаем модуль selinux.
# grep httpd /var/log/audit/audit.log | audit2allow -M my-httpd
Загружаем его.
# semodule -i my-httpd.pp
То же самое делаем для php.
# grep php /var/log/audit/audit.log | audit2allow -M my-php # semodule -i my-php.pp
Добавим нашу директорию /web/sites в соответствующие таблицы selinux для контента и логов.
# semanage fcontext -a -t httpd_sys_content_t "/web/sites(/.*)?" # semanage fcontext -a -t httpd_log_t "/web/sites(/.*)?/log(/.*)?"
И отдельно добавим каталог, куда web сервер сможет писать данные. Я покажу на примере правила для сайтов wordpress, где web сервер должен уметь писать в директорию wp-content для загрузки медиафайлов, установки тем и плагинов, а так же изменять файл wp-config.php.
# semanage fcontext -a -t httpd_sys_rw_content_t "/web/sites/\*/www/wp-content(/.\*)?" # semanage fcontext -a -t httpd_sys_rw_content_t "/web/sites/\*/www/wp-config.php"
Обновляем атрибуты файлов новым контекстом SELinux.
# restorecon -Rv /web/sites
В завершении настройки selinux для apache, добавим еще один параметр, без которого httpd не сможет писать файлы в указанные каталоги.
# setsebool -P httpd_unified 1
Теперь активируем защиту selinux и проверяем, что она работает.
# setenforce 1 # getenforce Enforcing
Режим работы Enforcing означает, что selinux работает. Убедиться, что модули загружены, можно командой.
# semodule -l | grep my-
В целом, по selinux все. Мы просто разрешили все, что веб сервер просил. По идее, надо вдумчиво во всех правилах разбираться и разрешать только то, что считаешь нужным. Я честно скажу, что selinux знаю не очень хорошо. Дальше загрузки готовых модулей и автоматического создания модулей с помощью audit2allow я не двигался. Руками модули никогда не писал. Если есть какой-то более осмысленный и правильный способ настройки selinux на кастомной конфигурации веб сервера, буду рад полезной информации.
Хорошая практическая статья по ручной настройке selinux для web сервера — https://habr.com/ru/post/322904/. Там же есть ссылки на другие статьи автора на тему selinux. Написано содержательно и наглядно, рекомендую для тех, кто будет знакомиться с технологией.
Настройка виртуальных хостов Apache?
Я уже подробно рассматривал как настроить Apache в отдельной статье. Поэтому не буду полностью расписывать здесь все конфигурационные файлы. Остановимся на файлах виртуальных хостов. Для удобства они вынесены в отдельные папки:
- /etc/apache2/sites-available
- /etc/apache2/sites-enabled
Ясно, что это разделение очень условно. Вы можете его убрать и добавлять свои виртуальные хосты прямо в основной конфигурационный файл. Все файлы из этих папок подключаются к нему с помощью директив Include. Но ведь так намного удобнее. В папке sites-available находятся все конфигурационные файлы, но они пока еще не активированы и отсюда не импортируются никуда. При активации нужного хоста на него просто создается ссылка в папку /etc/apache2/sites-enabled.
Для примера, создадим новый конфигурационный файл для виртуального хоста site1.ru. Для этого просто скопируем существующую конфигурацию для хоста по умолчанию — 000-default:
Сначала рассмотрим синтаксис того, что вы увидите в этом файле:
<VirtualHost адрес_хоста_для прослушивания:порт>ServerName доменServerAlias псевдоним_доменаServerAdmin емейл@администратораDocumentRoot /путь/к/файлам/сайтаErrorLog /куда/сохранять/логи/ошибок/error.logCustomLog /куда/сохранять/логи/доступа/access.log combined</VirtualHost>
Это минимальная конфигурация, которую вам нужно указать, чтобы создать виртуальный хост Apache. Конечно, здесь вы можете использовать и другие директивы Apache, такие как Deny, Allow и многие другие. А теперь рассмотрим наш пример для тестового сайта site1.ru:
Здесь мы используем звездочку вместо ip адреса, это значит, что веб-сервер будет слушать соединения на всех адресах, как на внешнем, так и на localhost. Порт 80, это порт по умолчанию. Затем указываем домен, электронный адрес администратора, и путь к папке, в которой будут находиться данные сайта. Две строчки Log говорят куда сохранять логи, но добавлять их необязательно. Дальше, нам нужно активировать этот хост. Мы можем вручную создать ссылку или использовать уже заготовленную команду:
Затем перезапустите Apache:
И нам осталось все это протестировать. Если ваш сервер имен еще не направляет запросы к домену на ваш ip, а вы хотите уже проверить как все работает, можно пойти обходным путем. Для этого достаточно внести изменения в файл /etc/hosts на машине, с которой вы собрались открывать сайт. Этот файл, такой себе локальный DNS. Если компьютер находит ip для домена в нем, то запрос в интернет уже не отправляется. Если вы собираетесь тестировать с той же машины, на которую установлен Apache2, добавьте:
Если же это будет другой компьютер, то вместо 127.0.0.1 нужно использовать адрес вашего сервера, на котором установлен Apache. Затем можете открыть сайт в браузере:
Установка PHP и PHP-FPM
Устанавливаем PHP и php-fpm следующей командой:
dnf install php php-fpm
* В CentOS 8 будет установлена версия php 7.2 и выше
Запускаем php-fpm и разрешаем его автозапуск:
systemctl enable php-fpm —now
Настройка связки NGINX + PHP
Открываем файл для настройки виртуального домена по умолчанию:
vi /etc/nginx/nginx.conf
В секции location редактируем параметр index на следующее значение:
location / {
index index.php index.html index.htm;
}
* добавляем index.php в начало списка. Если параметра index нет, создаем его.
А внутри секции server добавим следующее:
location ~ \.php$ {
set $root_path /usr/share/nginx/html;
fastcgi_pass unix:/run/php-fpm/www.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;
include fastcgi_params;
fastcgi_param DOCUMENT_ROOT $root_path;
}
* где /usr/share/nginx/html — корневой путь хранения скриптов; unix:/run/php-fpm/www.sock — файл для взаимодействия с php-fpm.
Открываем настройки php-fpm:
vi /etc/php-fpm.d/www.conf
Проверяем, что параметр listen настроен так:
listen = /run/php-fpm/www.sock
… иначе, меняем значение. После перезагружаем php-fpm:
systemctl restart php-fpm
* в данном примере мы указываем, что php-fpm будет использовать сокетный файл /run/php-fpm/www.sock для взаимодействия. Этот файл мы указали выше в настройке NGINX.
Проверяем правильность настроек nginx:
nginx -t
И перезагружаем его:
systemctl restart nginx
Создаем index.php в каталоге сайта по умолчанию со следующим содержимым:
vi /usr/share/nginx/html/index.php
<?php phpinfo(); ?>
Открываем в браузере IP-адрес нашего сервера. Теперь мы должны увидеть сводную информацию по PHP и его настройкам, например:
Установка php в CentOS 8
Установка php в Centos 8 сильно упростилась по сравнению с предыдущей версией, потому что в базовом репозитории хранится актуальная версия php 7.2, которой можно пользоваться. Пока нет необходимости подключать сторонние репозитории, так как версия 7.2 вполне свежа и актуальна. Если у вас нет необходимости использовать что-то новее, то можно остановиться на этой версии.
Устанавливаем php в CentOS 8, а так же некоторые популярные модули, которые могут пригодиться для того же phpmyadmin.
# dnf install php php-cli php-mysqlnd php-json php-gd php-ldap php-odbc php-pdo php-opcache php-pear php-xml php-xmlrpc php-mbstring php-snmp php-soap php-zip
Выполним перезапуск apache:
# systemctl restart httpd
Создадим файл в директории виртуального хоста и проверим работу php:
# mcedit /web/sites/z.serveradmin.ru/www/index.php
<?php phpinfo(); ?>
# chown apache. /web/sites/z.serveradmin.ru/www/index.php
Заходим по адресу http://z.serveradmin.ru/index.php
Вы должны увидеть вывод информации о php. Если что-то не так, возникли какие-то ошибки, смотрите лог ошибок виртуального хоста, php ошибки будут тоже там. Если вам необходима более свежая версия php, то читайте статью по обновлению php 7.2 до 7.4.
Где лежит php.ini
После установки часто возникает вопрос, а где хранятся настройки php? Традиционно они находятся в едином файле настроек. В CentOS php.ini лежит в /etc, прямо в корне. Там можно редактировать глобальные настройки для всех виртуальных хостов. Персональные настройки каждого сайта можно сделать отдельно в файле конфигурации виртуального хоста, который мы сделали раньше. Давайте добавим туда несколько полезных настроек:
# mcedit /etc/httpd/conf.d/z.serveradmin.ru.conf
Добавляем в самый конец, перед </VirtualHost>
php_admin_value date.timezone 'Europe/Moscow' php_admin_value max_execution_time 60 php_admin_value upload_max_filesize 30M
Для применения настроек нужно сделать restart apache. Если у вас полностью дефолтная установка, как у меня, то скорее всего вы увидите ошибку.
Суть ошибки в том, что у нас не загружен модуль mod_php. Проверим, где он подключается. Это файл /etc/httpd/conf.modules.d/15-php.conf.
<IfModule !mod_php5.c>
<IfModule prefork.c>
LoadModule php7_module modules/libphp7.so
</IfModule>
</IfModule>
Тут стоит проверка на запуск модуля. Он загружается только, если у нас загружен модуль prefork. Давайте попробуем его загрузить принудительно. Для этого комментируем все строки, кроме основной.
LoadModule php7_module modules/libphp7.so
Проверяем конфигурацию apache.
# apachectl -t
Apache is running a threaded MPM, but your PHP Module is not compiled to be threadsafe.
Получили новую ошибку. Смысл в том, что изначально apache сконфигурирован на работу модуля mpm_event, он подключается в конфиге /etc/httpd/conf.modules.d/00-mpm.conf.
LoadModule mpm_event_module modules/mod_mpm_event.so
Стандартный модуль mod_php скомпилирован с поддержкой модуля mpm_prefork. С другими он работать не будет. Таким образом, чтобы у нас нормально заработал php, нам надо вместо модуля mpm_event подключить модуль mpm_prefork. Для этого в конфиге 00-mpm.conf закомментируем подключение mpm_event_module и раскомментируем prefork.
LoadModule mpm_prefork_module modules/mod_mpm_prefork.so
После этого проверяйте конфигурацию и перезапускайте apache. Все должно заработать. Теперь в выводе phpinfo можно увидеть изменение настроек.
Я подробно разобрал эти ошибки, чтобы у вас было понимание, как все устроено и куда смотреть в случае проблем. Более подробно о работе и выборе mpm модулей читайте в официальной документации apache — http://httpd.apache.org/docs/2.4/mpm.html.
Настройка модулей Apache
Как я уже говорил, Apache — модульная программа, ее функциональность можно расширять с помощью модулей. Все доступные модули загрузчики и конфигурационные файлы модулей находятся в папке /etc/apache/mods-available. А активированные в /etc/apache/mods-enable.
Но вам необязательно анализировать содержимое этих папок. Настройка Apache 2.4 с помощью добавления модулей выполняется с помощью специальных команд. Посмотреть все запущенные модули можно командой:
Включить модуль можно командой:
А отключить:
После включения или отключения модулей нужно перезагрузить apache:
Во время выполнения одной из этих команд создается или удаляется символическая ссылка на файл модуля с расширением load в директории mods-available. Можете посмотреть содержимое этого файла, там только одна строка. Например:
Это к тому, что активировать модуль можно было просто добавив эту строчку в файл apache2.conf. Но принято делать именно так, чтобы избежать путаницы.
Настройки модулей находятся в той же папке, только в файле с расширением .conf вместо load. Например, посмотрим настройки того же модуля для сжатия deflate:
Файлы в папке conf-available, это такие же модули, только они установлены отдельно от apache, это может быть конфигурационные файлы для включения модуля php или любого другого языка программирования. Здесь работает все точно так же, только команды для включения и отключения этих модулей немного другие:
Как вы убедились, включать модули очень просто. Давайте включим несколько необходимых, но не включенных по умолчанию модулей:
Модули expires и headers уменьшают нагрузку на сервер. Они возвращают заголовок Not Modified, если документ не изменился с последнего запроса. Модуль expiries позволяет устанавливать время, на которое браузер должен кэшировать полученный документ. Rewrite позволяет изменять запрашиваемые адреса на лету, очень полезно при создании ЧПУ ссылок и т д. А последний для включения поддержки шифрования по SSL. Не забудьте перезагрузить apache2 после завершения настроек.
Удаление службы используя командную строку
На моей практике был случай, когда я удалил файлы веб-сервера, забыв перед этим остановить службу и удалить ее. Соответственно служба не работала, так как файлы были удалены, но висела в списках. При развертывании нового веб-сервера, а именно при попытки установить службу, консоль ругалась, что данная служба уже установлена.
Для решения данной проблемы пришлось удалить службу, выполнив в командной строке следующую команду:
C:\Windows\system32>sc delete ServiceName или C:\Windows\system32>sc delete "Service Name"
где ServiceName или «Service Name» имя удаляемой службы
По итогам изучения данного материала мы рассмотрели процесс установки локального веб-сервера, познакомились с главным конфигурационным файлом httpd.conf и его основными директивами. Так же мы рассмотрели механизмы управления службой Apache, такие как: запуск, остановка, удаление, просмотр версии.
На следующем шаге мы подключим модуль интерпретатора языка программирование PHP к установленному веб-серверу, и тем самым укажем веб-серверу, что он должен исполнять php скрипты.
Установка NGINX
Устанавливаем NGINX:
dnf install nginx
Внесем небольшую корректировку в файл nginx.conf:
vi /etc/nginx/nginx.conf
В секцию http добавим строку:
http {
…
server_names_hash_bucket_size 64;
….
}
* на практике, может встретиться ошибка could not build server_names_hash, you should increase server_names_hash_bucket_size: 32. Она возникает при большом количестве виртуальных серверов или если один из них будет иметь длинное название. Данная строка в конфиге исправит ситуацию.
Разрешаем автозапуск сервиса и запустим его:
systemctl enable nginx
systemctl start nginx
Проверим, что веб-сервер работает. Для этого открываем браузер на другом компьютере, который находится в одной сети и вводим в адресной строке IP-адрес сервера. В итоге мы должны увидеть заголовок «Welcome to nginx!»:
* обратите внимание, что данное приветствие может иметь и другой вид
Публикуем нашу базу на веб сервере.
Открываем конфигуратор нашей базы (Запуск 1С обязательно от имени администратора)
Переходим в Администрирование — «Публикация на веб-сервере»
Заполняем имя ЛАТИНСКИМИ БУКВАМИ БЕЗ ПРОБЕЛОВ (можно использовать подчеркивание)
Веб сервер Apache
Каталог — по сути произвольный каталог с файлами веб сервера для текущей базы. Желательно название каталога, что бы совпадало с названием базы (для простоты). Остальные флажки оставляем как на картинке. Смысл и необходимость каждого флажка можно будет разобрать позже.
Нажимаем «Опубликовать». Если при нажатии опубликовать вы видите сообщение
Невозможно записать c:\Program Files (x86)\Apache …. значит вы запустили 1С не от имени администратора. Закройте 1С и заново запустите (теперь «от имени администратора»)
Вы должны увидеть сообщение «Публикация выполнена»
На вопрос «Перезапустить ли веб-сервер» — всегда соглашаемся.
Пробуем открыть в броузере нашу базу. С текущего компьютера (где установлен веб-сервер)
И если все удачно — то с других компьютеров — http://192.168.0.189/UNF_InternetMagazin/
Диагностика и решение проблем
Если при запуске веб-сервера возникает ошибка, первостепенно требуется проверить корректность конфигурации.
При наблюдении синтаксической ошибки, исправляем её и перезапускаем веб-сервер. Если проблема сохранилась, выполняем команду для чтения подробного описания ошибки:
# systemctl status httpd.service
или
# journalctl -xe
Диагностика ошибки «Address already in use: AH00072: make_sock: could not bind to address»
Данная ошибка означает, что веб-сервер пытается запуститься на порту, который уже используется. В тексте ошибки будет присутствовать адрес и порт, например:
(98)Address already in use: AH00072: make_sock: could not bind to address 1.2.3.4:80
Проверяем, какой из текущих процессов использует порт 80:
# netstat -tap --numeric-ports |grep :80
Если порт используется другим сервисом, например, Nginx, и это нормально, значит, Apache является backend-ом и должен слушать другой порт. Ищем, в каком конфигурационном файле допущена ошибка:
# grep -rl ":80" /etc/httpd/
- Находим файл, изменяем значение и перезагружаем веб-сервер.
- Если на порту «завис» процесс Apache, прерываем его работу его с помощью команды и перезапускаем веб-сервер.
Настройка HTTPS в Apache
Создание ключа и ssl-сертификата
Использование самоподписанных сертификатов хоть и защищает от пассивного прослушивания, тем не менее не гарантирует клиентам, что сервер является именно тем сервером, который им нужен. Преимуществом самоподписанных сертификатов является их бесплатность. Сертификат, подписанный компанией-сертификатором (Certificate authority), стоит денег.
Для создания ключа и сертификата вводим команду:
openssl req -new -x509 -days 30 -keyout server.key -out server.pem
На вопрос «Enter PEM pass phrase:» отвечаем паролем, подтверждаем и запоминаем.
На все последующие вопросы отвечаем произвольно, можно просто щелкать по Enter, соглашаясь с предложенными вариантами, только на вопрос «Common Name (eg, YOUR name) []:» отвечаем именем сайта, для которого создаем сертификат, например www.example.com.
После ответа на все вопросы в директории должны появиться два новых файла — (ключ) и (сертификат).
Чтобы использовать сгенерированный ключ, нужно знать пароль, введённый нами, и Apache будет спрашивать его у нас при загрузке, а к чему нам лишние вопросы от демонов? 
Поэтому снимаем пароль с ключа:
cp server.key{,.orig}
openssl rsa -in server.key.orig -out server.key
rm server.key.orig
Скопируем их в /etc/ssl и назначим файлу ключа права чтения только администратору:
sudo cp server.pem etcsslcerts sudo cp server.key etcsslprivate sudo chmod 0600 etcsslprivateserver.key
Настройка Apache
Для начала необходимо активировать :
sudo a2enmod ssl
А затем включить настройки HTTPS сайта по умолчанию:
sudo a2ensite default-ssl
Теперь необходимо отредактировать файл с настройками HTTPS сайта по умолчанию, указав в нём пути к вашим сертификатам. Сам файл называется (или ).
В этом файле рекомендуется после директивы
SSLEngine on
добавить строчку
SSLProtocol all -SSLv2
чтобы запретить использование устаревшего протокола SSLv2.
Дальше вам необходимо отредактировать параметры, ответственные за сертификаты.
# Публичный сертификат сервера SSLCertificateFile /etc/ssl/certs/server.pem # Приватный ключ сервера SSLCertificateKeyFile /etc/ssl/private/server.key
Теперь просто перезагрузите Apache:
sudo service apache2 restart
И если все параметры указаны верно, ваши сайты станут доступны по HTTPS.
Протокол HTTPS работает по 443 порту, поэтому если сервер находится за шлюзом, то необходимо на нём пробросить данный порт.
Перенаправление HTTP запросов на HTTPS
Если вы хотите запретить использование HTTP, то самым разумным будет перенаправлять все HTTP запросы к страницам на их HTTPS адрес. Сделаем это с помощью . Если он не включён — включаем:
sudo a2enmod alias sudo service apache2 restart
Затем изменяем файл , отвечающий за виртуальный хост по умолчанию для HTTP запросов. В этот файл добавляем директиву
Redirect / https://example.com/
При этом все настройки директорий можно удалить, поскольку по HTTP на ваши сайты всё равно будет не попасть.
Всё, теперь ещё раз перезапустите Apache и убедитесь, что при заходе по HTTP вы автоматически перенаправляетесь на HTTPS-страницу.
3: Настройка перезаписи URL-адресов
Теперь можно создать базовые правила перезаписи URL-адресов, которые будут преобразовывать чистые ссылки в реальные пути к страницам. Рассмотрим настройку на примере ссылки:
Для начала создайте страницу about.html в корневом каталоге веб-сервера:
Скопируйте и вставьте в файл такой HTML-код:
Обратите внимание: если вы введёте ссылку:
вы получите ошибку 404. Если вы хотите, чтобы пользователи могли получить доступ к странице, не указывая расширения .html, вы можете создать правила перезаписи.
Все правила перезаписи RewriteRules имеют такой формат:
Где:
- RewriteRule – директива перезаписи.
- pattern – регулярное выражение, которое определяет необходимую строку в URL-адресе.
- substitution – путь к файлу.
- flags – дополнительные параметры, которые управляют поведением правила.
Откройте .htaccess:
После первой строки добавьте следующее правило RewriteRule , а затем сохраните файл:
В данном случае ^about$ – это шаблон, about.html – путь к файлу, а – флаг. Рассмотрим это правило подробнее:
- ^ определяет начало искомого шаблона URL-а (после your_server_ip/).
- $ – конец шаблона.
- about – собственно шаблон, слово, которое нужно найти в ссылке.
- about.html – путь к файлу этой страницы.
- – флаг, который отключает чувствительность к регистру.
Теперь откройте ссылку http://your_server_ip/about в браузере. Добавленное в .htaccess правило позволяет получить доступ к странице по следующим URL-адресам:
- http://your_server_ip/about;
- http://your_server_ip/About (поскольку правило не учитывает регистр);
- http://your_server_ip/about.html (оригинальная ссылка будет работать всегда).
А эти URL-адреса работать не будут:
- http://your_server_ip/about/ (согласно добавленному правилу (символ $), после about ничего больше быть не может).
- http://your_server_ip/contact (потому что contact не совпадает со строкой about).
Теперь у вас есть простой файл .htaccess, в котором хранится базовое правило перезаписи ссылок. Ниже вы найдёте несколько полезных примеров наиболее часто используемых директив.
Управление службой Apache
Для управления запуском и остановкой сервиса Apache можно использовать «ApacheMonitor». Откройте директорию веб-сервера bin («C:\Apache24\bin») и запустите файл: ApacheMonitor.exe. В системном трее появится значок Apache, с помощью которого можно быстро запускать/останавливать службу Apache.
А также, так как сервис Apache устанавливается как служба, после его установки, управлять его запуском/остановкой можно в окне списка служб («Пуск» → пункт «Панель управления» → «Администрирование» → «Службы»)
При установки Apache, служба, по умолчанию получает имя «Apache» или «Apache24». Если, в силу каких либо причин, имя службы нас не устраивает, есть возможность задать собственное имя, используя в командной строке параметр «-n» c указанием имени службы через пробел. (Если в имени службы содержится пробел необходимо обернуть его в кавычки, т. е. «name service»). Рассмотрим дополнительно команды для управления сервисом Apache:
устанавливаем службу
C:\Apache24\bin\httpd.exe -k install или C:\Apache24\bin\httpd.exe -k install -n name_service C:\Apache24\bin\httpd.exe -k install -n "name service"
запускаем службу
C:\Apache24\bin\httpd.exe -k start или C:\Apache24\bin\httpd.exe -k start -n name_service C:\Apache24\bin\httpd.exe -k start -n "name service"
останавливаем службу
C:\Apache24\bin\httpd.exe -k stop или C:\Apache24\bin\httpd.exe -k stop -n name_service C:\Apache24\bin\httpd.exe -k stop -n "name service"
удаляем службу
C:\Apache24\bin\httpd.exe -k uninstall или C:\Apache24\bin\httpd.exe -k uninstall -n name_service C:\Apache24\bin\httpd.exe -k uninstall -n "name service"
получаем информации о версии службы
C:\Apache24\bin\httpd.exe -V
получаем конфигурацию службы
C:\Apache24\bin\httpd.exe -k config или C:\Apache24\bin\httpd.exe -k config -n name_service C:\Apache24\bin\httpd.exe -k config -n "name service"
Данная команда тестирует конфигурационный файл httpd.conf и отображает ошибки
Управлять службами также можно, используя в командной строке команду «net». Рассмотрим несколько примеров.
получаем список служб
C:\Windows\system32>net start
запускаем службу
C:\Windows\system32>net start Apache2.4 или C:\Windows\system32>net start "name service"
останавливаем службу
C:\Windows\system32>net stop Apache2.4 или C:\Windows\system32>net stop "name service"
