Пример 2: включение CGI printenv[править]
Чтобы разрешить CGI, необходимо включить соответствующий модуль:
# a2enmod cgi
Module cgi installed;
run service httpd2 condreload to fully enable.
# service httpd2 condreload
Reloading httpd2 service:
Разумеется, пакеты и должны быть установлены:
# rpm -qa apache2-cgi\* apache2-cgi-bin-test-cgi-2.2.17-alt2 apache2-cgi-bin-2.2.17-alt2 apache2-cgi-bin-printenv-2.2.17-alt2
Однако покажет ошибку. Дело в том, что файл /var/www/cgi-bin/printenv после установки Centaurus — символьная ссылка на неисполняемый файл в /usr/share/apache2/cgi-bin:
# ls -l /var/www/cgi-bin /usr/share/apache2/cgi-bin/ /usr/share/apache2/cgi-bin/: итого 8 -rw-r--r-- 1 root root 288 Дек 27 01:43 printenv -rw-r--r-- 1 root root 779 Окт 14 20:33 test-cgi
/var/www/cgi-bin: итого 0 lrwxrwxrwx 1 root root 35 Мар 5 14:43 printenv -> /usr/share/apache2/cgi-bin/printenv lrwxrwxrwx 1 root root 35 Мар 3 12:19 test-cgi -> /usr/share/apache2/cgi-bin/test-cgi
Для управления тестовыми CGI-сценариями имеются соответствующие control-сценарии. В Centaurus достаточно выполнить
# control cgi-bin_printenv symlink_webmaster_exec
После этого файл станет исполняемым и сценарий заработает:
# ls -l /var/www/cgi-bin /usr/share/apache2/cgi-bin/ /usr/share/apache2/cgi-bin/: итого 8 -rwxr-xr-x 1 root root 288 Дек 27 01:43 printenv -rw-r--r-- 1 root root 779 Окт 14 20:33 test-cgi
/var/www/cgi-bin: итого 0 lrwxrwxrwx 1 root webmaster 35 Мар 5 14:47 printenv -> /usr/share/apache2/cgi-bin/printenv lrwxrwxrwx 1 root root 35 Мар 3 12:19 test-cgi -> /usr/share/apache2/cgi-bin/test-cgi
На компьютере — web-сервере Apache2 (Часть 2)
Скопировать keytab (файл /tmp/http.keytab) с контроллера домена на web-сервер в каталог /etc/apache2/.
Выставить права на keytab:
sudo chown www-data /etc/apache2/http.keytabsudo chmod 644 /etc/apache2/http.keytab
В конфигурацию виртуального хоста virtualhost в файле /etc/apache2/sites-available/000-default.conf внести настройки:
<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /var/www
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
<Directory /var/www>
AuthType Kerberos
# Имя реалма Керберос - имя домена ЗАГЛАВНЫМИ буквами
KrbAuthRealms ASTRA.DOMAIN
# Полное доменное имя сервиса (имя ранее созданной службы HTTP):
KrbServiceName HTTP/[email protected]
# Имя файла, в котором сохранены ключи
Krb5Keytab /etc/apache2/http.keytab
KrbMethodNegotiate on
KrbMethodK5Passwd off
require valid-user
KrbSaveCredentials on
</Directory>
</VirtualHost>
Создать каталог для виртуального сервера:
На компьютере — web-сервере назначить мандатные атрибуты каталогу с виртуальным сервером:
sudo pdpl-file 3:0:0xffffffffffffffff:ccnr /var/www/sudo pdpl-file 3:0:0xffffffffffffffff:ccnr /var/www/html/
Перезапустить web-сервер:
sudo systemctl restart apache2
Проверка работы мандатных ограничений
На компьютере — контроллере домена создать доменного пользователя, и выставить ему ненулевой «максимальный уровень конфиденциальности» (например, 1).
На компьютере — web-сервере в папке виртуального сервера /var/www/html/ создать 2 файла и установить ненулевую мандатную метку на файл 1.html:
echo «Hello world! 0» | sudo tee /var/www/html/0.htmlecho «Hello world! 1» | sudo tee /var/www/html/1.htmlsudo pdpl-file 1:0:0 /var/www/html/1.html
Должно получиться так:
На любом компьютере, который должен выступать в роли клиента, в web-браузере negotiate авторизацию (для чего открыть страницу about:config и добавить http:// в параметры network.negotiate-auth.delegation-uris и network.negotiate-auth.trusted-uris):
После чего зайти на клиентский компьютер под пользовательской доменной учетной записью с нулевым уровнем конфиденциальности и попытаться получить доступ к странице с ненулевым уровнем конфиденциальности http://client.astra.domain/html/1.html. Результатом должен стать отказ в доступе:
При этом доступ к странице с нулевым уровнем конфиденциальности http://client.astra.domain/html/0.html должен предоставляться:
При входе на клиентский компьютер под пользовательской доменной учетной записью с ненулевым уровнем конфиденциальности должны быть доступны обе страницы.
Основные отличия от Debian[править]
Ссылки с описанием Debian`овского оригинала я не нашёл.
- Конфигурационные файлы conf/{mods,sites}-{available,enabled} — передраны из Debian без существенных изменений. По их образу и подобию созданы conf/{ports,extra}-{available,enabled}
conf/mods-available/.load — файлы обеспечивающие загрузку модулей и содержащие описание их зависимостей. Примерной формат:
. Содержимое:
# Depends: <имя требуемого модуля> LoadModule ...
-
- conf/mods-available/<имя модуля>.conf — конфигурация для модуля <имя модуля> (если она нужна).
- conf/sites-available/*.conf — конфигурации для сайтов (виртуалхостов).
- conf/ports-available/*.conf — конфигурирования слушаемых портов.
- conf/extra-available/*.conf — конфигурирования компонент общих для всех сайтов. За прототип взято содержимое conf/extra из апстримного apache-2.2.4 (не всё: часть переехала в другие каталоги).
- conf/{mods,sites,ports,extra}-enabled/*.{conf,load} — симлинки на соответствующие conf/{mods,sites,ports,extra}-available/*.{conf,load}, используемые в httpd2.conf.
-
conf/include/*.conf — конфигурационные файлы включаемые в другие через:
Include conf/include/...
- Утилиты /usr/sbin/a2{en,dis}{mod,site}, управляющие созданием/удалением симинков conf/*-enabled/* на соответствующие conf/*-available/* взяты из Debian без существенных изменений. /usr/sbin/a2{en,dis}{port,extra} — добавлены, и имеют аналогичные функционал и назначение.
- Добавлена система автоматизированного управления включением/выключением компонент. Состоит из утилиты /usr/sbin/a2chkconfig и конфигов conf/{mods,sites,port,extra}-start.d/*.conf для неё.
- /usr/sbin/a2chkconfig — покомпонентно обрабатывает conf/*-start.d/*.conf (файлы обрабатываются в порядке их имён, обработанные позже имеют приоритет) и вызывает соответствующие a2{en,dis}{mod,site} для компонент упомянутых в конфигах.
- conf/{mods,sites,port,extra}-start.d/*.conf — файлы конфигурации для a2chkconfig. Формат:
<имя компонента>={yes,no}
Ускорение работы Apache изменениями во время выполнения
Чтобы повысить производительность сервера, нужно регулярно измерять производительность и осуществлять тонкую настройку конфигурации. Наиболее важные параметры, которые нужно оптимизировать:
Поиск DNS
Apache может тратить время на определение хоста каждого IP, с которого приходит запрос. Это замедляет обработку запроса, а также приводит к пустой трате ресурсов. Чтобы избежать этого, нужно отключить опцию HostnameLookups.
При настройке директив Allow from или Deny from используйте IP-адреса вместо доменных имён. Иначе будет осуществляться двойной поиск имени DNS, который уменьшит производительность сервера.
Настройка AllowOverride
Если задана опция AllowOverride, то Apache попытается открыть файл .htaccess в каждой папке, которую он посещает. Эти дополнительные запросы к файловой системе увеличивают время отправки ответа с сервера.
Поэтому лучше отключить эту опцию. Если переопределение настроек в файлах .htaccess необходимо в определённой папке, нужно разрешить это только для данного каталога.
Настройки FollowSymLinks и SymLinksIfOwnerMatch
Настройка Apache FollowSymLinks сообщает серверу, что нужно проверять символические ссылки и проходить по ним. Если она имеет значение Off, Apache придётся выполнять дополнительные проверки, что замедлит его работу.
Если установлена директива SymLinksIfOwnerMatch, сервер будет проходить по символическим ссылкам, только если владелец целевого файла тот же, что и владелец ссылки. Это также влияет на скорость работы Apache.
Лучше всего активировать директиву FollowSymLinks и выключить директиву ‘SymLinksIfOwnerMatch’. Но это может привести к проблемам с безопасностью, поэтому окончательное решение остается за вами.
Согласование содержимого (Content Negotiation)
Согласование содержимого позволяет клиентам выбирать формат данных, получаемых от сервера. Рекомендуется избегать согласования содержимого для быстрого ответа.
Если согласование содержимого необходимо для сайта, можно снизить задержки, используя файлы type-map вместо директивы Options MultiViews. Ее применение увеличивает задержку.
Настройка MaxClients
Настройка MaxClients устанавливает лимит количества одновременных запросов, которое может поддерживаться Apache. Если это значение слишком мало, запросы станут в очередь, и не будут обрабатываться.
Большое значение параметра может загрузить оперативную память и повлиять на скорость ответов Apache. Необходимо выбрать оптимально значение исходя из объёма доступной памяти и ресурсов, потребляемых процессом.
Настройки MinSpareServers, MaxSpareServers и StartServers
MaxSpareServers и MinSpareServers определяют количество дочерних процессов, которые будут находиться в состоянии ожидания обработки запросов. Эти параметры важны, потому что создание дочернего процесса отнимает ресурсы.
Если значение MinSpareServers слишком низкое, и на сервер поступает одновременно несколько запросов, Apache создаст дополнительные дочерние процессы. Это снижает возможность быстрого ответа на запрос клиента.
Значение MaxSpareServers не должно быть слишком большим. Так как стоящие в очереди на обработку дочерние процессы потребляют лишние серверные мощности. Нужно установить эти значения в оптимальном диапазоне, чтобы сбалансировать использование ресурсов и производительность.
Директива StartServers устанавливает количество дочерних серверных процессов, которые создаются при старте сервера. Если запросов много, а Apache часто перезагружается, нужно установить относительно большое значение.
Настройка MaxRequestsPerChild
Директива MaxRequestsPerChild устанавливает лимит количества запросов, которое будет обрабатывать каждый дочерний процесс. Слишком малое значения может привести к перегрузке сервера при создании новых процессов. Поэтому нужно установить это значение в диапазоне нескольких тысяч, чтобы ускорить работу Apache.
Настройка KeepAlive и KeepAliveTimeout
KeepAlive используется для поддержки единого соединения для передачи данных веб-страницы. Благодаря чему не тратится время на создание нового подключения для каждого файла.
KeepAliveTimeout определяет время ожидания следующего запроса. Если значение большое, дочерние процессы могут расходовать ресурсы, ожидая следующего запроса. Оптимальное значение – 2-5 секунд для небольших объемов трафика и 10 секунд для высоконагруженных серверов.
Timeout
Устанавливает время ожидания запроса от посетителя. При больших объемах трафика значение параметра должно быть не менее 120 секунд. Но лучше держать это значение минимальным. Это позволяет предотвратить излишнее расходование ресурсов.
5 шагов для ускорения работы Apache
Ускорить работу Apache можно на двух основных стадиях:
- Во время компиляции – настройки при установке сервера.
- Во время выполнения — установка параметров, влияющих на сервер во время его работы.
Настройки для ускорения Apache во время компиляции
Нужно выбирать вариант установки Apache, исходя из ваших требований. Это поможет создать быстрый и эффективный веб-сервер.
Загружайте только нужные модули
В Apache функциональность реализуется путем добавления модулей. Они бывают двух типов: статические и динамические (общие).
Чтобы посмотреть список модулей, поддерживаемых вашим сервером, используйте команду apachectl -M. Статические модули компилируются в бинарные файлы httpd, а динамические загружаются непосредственно во время выполнения.
Статические и динамические модулиключевые различия
| Статические модули | Динамические модули |
| Компилируются в бинарные файлы | Добавляются во время выполнения |
| Требуют перекомпиляции кода | Перекомпиляция не требуется |
| Быстро загружаются | Замедляют веб-сервер |
Чем больше статических модулей в бинарных файлах, тем быстрее работает веб-сервер. Но они требуют перекомпиляции Apache каждый раз, когда нужно что-то изменить. Из-за этого динамические модули или DSO используются чаще, поскольку они могут быть скомпилированы отдельно и загружены во время выполнения.
Но большое количество динамических или общих модулей может замедлить работу сервера Apache и сайта
Поэтому при выборе модулей требуется соблюдать осторожность
Чтобы увеличить скорость работы и производительность, используйте минимальное количество динамических модулей, поскольку они уменьшают объем доступной памяти.
Выберите правильный MPM
В Apache используются MPM (мульти-процессинговые модули), которые обрабатывают запросы, приходящие на сервер. Они прослушивают сетевые порты сервера, принимая запросы и создавая дочерние процессы.
MPM бывают двух типов: Prefork и Worker. В MPM Prefork каждый процесс httpd обрабатывает один сетевой запрос. Это более безопасно по сравнению с MPM Worker, но требует большего количества памяти и ресурсов.
MPM – Prefork и Worker
| MPM Prefork | MPM Worker |
| Один поток | Несколько потоков |
| Использует больше ресурсов | Использует меньше памяти |
| Отказоустойчив | Справляется с большим трафиком |
При использовании MPM Worker Apache работает в режиме многопоточного сервера, где каждый отвечает за свой запрос. Этот вариант подходит для обработки большего трафика при ограниченных мощностях сервера.
По умолчанию большинство установок Apache используют модуль Prefork. Он применяется для обработки больших объемов трафика. Вы можете проверить, какой модуль MPM использует ваш сервер при помощи следующей команды:
Определение типа MPM на вашем веб—сервере Apache
В Apache 2.4 появилась поддержка э MPM модуля Event, который может обрабатывать множественные запросы внутри одного потока. Поэтому он работает даже быстрее, чем модуль Worker.
Конфигурации виртуальных хостов
Стандартный виртуальный хост находится в файле 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. После включения или отключения модуля нужно перезапускать веб-сервер.
Оригинальный httpd.conf
Оригинальный конфигурационный файл httpd.conf, созданный инсталятором Apache, на основе инструкций по инсталяции, приведенных в этой статье, можно скачать тут: httpd.conf.original.
Последнее обновление статьи: 2011/09/08
| Серьезная уязвимость Apache (все версии младше 2.2.20) |
| Установка и настройка PHP, MySQL и Apavhe |
| Конфигурационные директивы Apache файла http.conf |
| Русскоязычный перевод комментариев httpd.conf |
| PHP — как установить и настроить |
| MySQL — как установить и настроить |
Опубликовано: 2011/08/29
HTML-код ссылки на эту страницу:
<a href=»https://petrenco.com/apache.php?txt=84″ target=»_blank»>Apache — установка и настройка.</a>
144991
3: Настройка аутентификации Apache
Файл паролей с необходимыми данными готов. Теперь нужно настроить Apache, чтобы он проверял этот файл перед обслуживанием закрытого контента. Это можно сделать двумя способами: добавить информацию о файле паролей в виртуальный хост или создать файлы .htaccess в тех каталогах, содержимое которых нужно защитить. Обычно использовать виртуальный хост удобнее. Но если в вашем случае обычные пользователи системы должны иметь возможность самостоятельно управлять доступом, лучше добавить файлы .htaccess.
Выберите наиболее подходящий метод настройки и следуйте инструкциям соответствующего раздела.
Вариант 1: Настройка аутентификации через виртуальный хост
Этот метод обеспечивает более высокую производительность, поскольку веб-серверу не придется читать дополнительные конфигурационные файлы. Для такой настройки вам нужен доступ к конфигурации, который есть не у всех пользователей.
Откройте файл виртуального хоста того сайта, доступ к которому нужно ограничить. В данном мануале используется стандартный файл default-ssl.conf , который поставляется вместе с apache.
Внутри файл выглядит так (для удобства закомментированные строки опущены):
В Apache аутентификация настраивается на основе каталогов. Чтобы настроить ее, сначала найдите раздел каталога, к которому нужно ограничить доступ, в блоке <Directory ___>. Здесь мы для примера показываем, как ограничить доступ к корневому каталогу (а вы при необходимости укажите другой каталог):
В блоке этого каталога нужно указать тип аутентификации (в данном случае это Basic). В AuthName укажите имя, которое будет отображаться при запросе учетных данных. В директиве AuthUserFile укажите созданный ранее файл паролей. Установите значение valid-user для директивы Require, чтобы разрешить доступ к контенту только зарегистрированным пользователям.
Сохраните и закройте файл.
Проверьте файл на наличие ошибок:
Команда должна вернуть:
После этого можете перезапустить веб-сервер. Система systemctl не отображает на экране вывода некоторых команд управления сервером, потому состояние сервера после его перезапуска нужно запросить вручную:
Теперь пользователь должен будет ввести пароль, чтобы просматривать каталог.
Вариант 2: Настройка аутентификации с помощью файлов .htaccess
Apache может управлять аутентификацией с помощью файлов .htaccess. При этом Apache перечитывает каждый такой файл, что, конечно, отражается на производительности. По этой причине мы рекомендуем настраивать веб-сервер согласно первому варианту. Вариант 2 подходит, если вы уже используете файлы .htaccess или хотите предоставить пользователям без прав root возможность управлять ограничениями.
Чтобы включить поддержку аутентификации по файлам .htaccess, откройте конфигурационный файл Apache:
Найдите блок <Directory> для каталога /var/www (document root по умолчанию). Чтобы включить поддержку файлов .htaccess, нужно изменить значение директивы AllowOverride с None на All.
Сохраните и закройте файл.
Затем нужно добавить файл .htaccess в тот каталог, доступ к которому вы хотите ограничить. Мы для примера покажем ниже, как закрыть доступ к каталогу document root, /var/www/html (то есть ко всему сайту). Чтобы ограничить доступ к другому каталогу, внесите в код соответствующие поправки.
В этом файле нужно указать тип аутентификации, в данном случае это Basic. В AuthName укажите имя, которое будет отображаться при запросе учетных данных. В директиве AuthUserFile укажите созданный ранее файл паролей. Для директивы Require укажите значение valid-user, чтобы открыть доступ к контенту только тем пользователям, которые могут пройти аутентификацию.
Сохраните и закройте файл. Перезапустите веб-сервер, чтобы обновить настройки.
Запуск Apache 2.4 с модулем 1С внутри Docker контейнера
Про Apache и про Linux слышали, наверное, все. А вот про Docker пока нет, но он сильно набирает популярность последнее время и не зря. Поделюсь своим опытом и дам пошаговую инструкцию настройки веб-сервера Apache с модулем 1С внутри Docker контейнера на Linux хосте. При этом сам сервер 1С может находиться совсем на другой машине и на другой операционной системе
Это не важно, главное чтобы Apache смог достучаться до сервера 1С по TCP. В статье дам подробное пояснение по каждой используемой команде со ссылками на документацию по Docker, чтобы не создавалось ощущение непонятной магии
Также прилагаю git репозиторий с описанием всей конфигурации, можете попробовать развернуть у себя буквально за 10 минут.
Пример 1: переход на другой домен
Предположим, у вас есть сайт, который пользуется популярностью, но в какой-то момент у вас возникла необходимость сменить его домен. Конечно, вы не можете просто переместить контент на новый домен, а старый забросить: так вы потеряете своих посетителей. Кроме того, ссылки на ваш сайт, расположенные на других сайтах, перестанут работать, если вы просто перенесёте контент на новый домен и не оставите никакой информации о его новом местонахождении. Все это приведёт к снижению трафика. Как переместить контент сайта на новый домен и не потерять аудиторию?
В таком случае нужно настроить редирект со старого домена (например, domain1.com) на новый (domain2.com). Чтобы навсегда сменить доменное имя сайта, используйте постоянный редирект. Благодаря этому браузер сможет перенаправлять поступающий трафик на новый домен.
Итак, предположим, что на данный момент сайт обслуживается по домену domain1.com, а его виртуальный хост находится в /etc/apache2/sites-available/domain1.com.conf:
Виртуальный хост для нового домена сайта, /etc/apache2/sites-available/domain2.com.conf, должен выглядеть так:
Теперь измените настройки виртуального хоста domain1.com и добавьте в них постоянный редирект на domain2.com:
В данном случае используется директива RedirectMatch, а не Redirect, поскольку сайт состоит из нескольких страниц. Регулярное выражение ^/(.*)$ совпадает с любым текстом, идущим в URL-адресе после /. Таким образом, http://domain1.com/index.html будет перенаправляться на http://domain2.com/index.html.
Чтобы настроить постоянный редирект, нужно просто добавить опцию permanent в директиву RedirectMatch.
Примечание: После изменения виртуального хоста нужно перезапустить Apache, чтобы обновить настройки:
Настройка
Для применения изменений в настройках необходимо перезапустить демон Apache:
sudo service apache2 restart
/etc/apache2/
|-- apache2.conf
| `-- ports.conf
|-- mods-enabled
| |-- *.load
| `-- *.conf
|-- conf-enabled
| `-- *.conf
`-- sites-enabled
`-- *.conf
Настройки модулей расположены в директории /etc/apache2/mods-available. Для подключения или отключения модулей (настроек модулей) следует использовать соответствующие команды или . Пример подключения модуля:
sudo a2enmod <mod-name>
Свои настройки следует сохранять в файлы, расположенные в директории /etc/apache2/conf-available. Для подключения или отключения своих настроек следует использовать соответствующие команды или . Пример подключения файла со своими настройками:
sudo a2enconf <config-name>
Настройки виртуальных хостов следует сохранять в файлы, расположенные в директории /etc/apache2/sites-available. Для подключения виртуальных хостов следует использовать соответствующие команды или . Пример подключения виртуального хоста:
sudo a2ensite <site-name>
Кодировка по умолчанию
Для указания кодировки по умолчанию следует использовать директиву в файле /etc/apache2/conf-available/charset.conf (или раскомментировать соответствующую строку):
AddDefaultCharset UTF-8
Виртуальные хосты
Файлы настроек виртуальных хостов хранятся в /etc/apache2/sites-available/*.conf. По умолчанию в Apache уже настроен один виртуальный хост. Его настройки лежат в файле 000-default.conf. Вы можете использовать этот виртуальный хост в качестве примера.
Пример настройки виртуального хоста:
<VirtualHost *:80>
#Имя хоста
ServerName host1.server1
#Корневая папка хоста
DocumentRoot /var/www/host1.server1
<Directory /var/www/host1.server1>
#Разрешение на перезапись всех директив при помощи .htaccess
AllowOverride All
</Directory>
</VirtualHost>
Назовите файл настройки именем вашего хоста host1.server1.conf и сохраните.
После создания файла настроек допишите в /etc/hosts имя вашего хоста:
127.0.0.1 host1.server1
Для включения созданного виртуального хоста используется утилита :
sudo a2ensite host1.server1
Отключается хост аналогично утилитой :
sudo a2dissite host1.server1
mod_userdir
Модуль позволяет использовать директории, находящиеся в домашних директориях пользователей для хранения веб страниц. По умолчанию Apache ищет запрашиваемые страницы в директории ~/public_html
mkdir ~public_html
Чтобы включить , выполните:
sudo a2enmod userdir
и добавьте необходимого пользователя в группу www-data:
sudo adduser $USER www-data
после чего перезагрузите Apache:
sudo service apache2 restart
Страницы будут доступны по адресу http://localhost/~username, где username — имя пользователя.
CGI
Если Вы хотите запускать на сервере cgi-скрипты, подключите модуль командой
sudo a2enmod cgi
По умолчанию cgi-скрипты размещаются в директории /usr/lib/cgi-bin, но вы можете разместить их где угодно,
указав это в настройках своего виртуального хоста, либо глобально для всех хостов в файле
/etc/apache2/conf-enabled/serve-cgi-bin.conf.
Eсли ваш сервер работает во внешней сети, то в целях безопасности настоятельно рекомендуется размещать cgi-скрипты вне корневой директории виртуального хоста
