Как установить apache на ubuntu 20.04 и разместить веб-сайт

The HTTP/2 protocol

HTTP/2 is the evolution of the world’s most successful application layer protocol, HTTP.
It focuses on making more efficient use of network resources. It does not change the fundamentals
of HTTP, the semantics. There are still request and responses and headers and all that. So, if
you already know HTTP/1, you know 95% about HTTP/2 as well.

There has been a lot written about HTTP/2 and how it works. The most normative is, of course,
its RFC 7540
(also available in more readable formatting, YMMV).
So, there you’ll find the nuts and bolts.

But, as RFC do, it’s not really a good thing to read first. It’s better to first understand
what a thing wants to do and then read the RFC about how it is done. A much
better document to start with is http2 explained
by Daniel Stenberg, the author of curl. It is available in
an ever growing list of languages, too!

Too Long, Didn’t read: there are some new terms and gotchas that need to be kept in mind while reading this document:

Настройка Apache

Уже прошло то время, когда конфигурация Apache хранилась в одном файле. Но оно и правильно, когда все распределено по своим директориям, в конфигурационных файлах легче ориентироваться.

Все настройки содержатся в папке /etc/apache/:

• Файл /etc/apache2/apache2.conf отвечает за основные настройки
• /etc/apache2/conf-available/* — дополнительные настройки веб-сервера
• /etc/apache2/mods-available/* — настройки модулей
• /etc/apache2/sites-available/* — настойки виртуальных хостов
• /etc/apache2/ports.conf — порты, на которых работает apache
• /etc/apache2/envvars

Как вы заметили есть две папки для conf, mods и site. Это available и enabled. При включении модуля или хоста создается символическая ссылка из папки available (доступно) в папку enable (включено). Поэтому настройки лучше выполнять именно в папках available. Вообще говоря, можно было бы обойтись без этих папок, взять все и по старинке свалить в один файл, и все бы работало, но сейчас так никто не делает.

Сначала давайте рассмотрим главный файл конфигурации:

Timeout — указывает как долго сервер будет пытаться продолжить прерванную передачу или прием данных. 160 секунд будет вполне достаточно.

KeepAlive On — очень полезный параметр, позволяет передавать несколько файлов, за одно соединение, например, не только саму html страницу, но и картинки и css файлы.

MaxKeepAliveRequests 100 — максимальное количество запросов за одно соединение, чем больше, тем лучше.

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

User, Group — пользователь и группа, от имени которых будет работать программа.

HostnameLookups — записывать в логи вместо ip адресов доменные имена, лучше отключить, чтобы ускорить работу.

LogLevel — уровень логирования ошибок. По умолчанию используется warn, но чтобы логи заполнялись медленнее достаточно включить error

Include — все директивы include отвечают за подключение рассмотренных выше конфигурационных файлов.

Директивы Directory отвечают за настройку прав доступа к той или иной директории в файловой системе. Синтаксис здесь такой:

Здесь доступны такие основные опции:

AllowOverride — указывает нужно ли читать .htaccess файлы из этой директории, это такие же файлы настроек и таким же синтаксисом. All — разрешать все, None — не читать эти файлы.

DocumentRoot — устанавливает из какой папки нужно брать документы для отображенияа пользователю

Options — указывает какие особенности веб-сервера нужно разрешить в этой папке. Например, All — разрешить все, FollowSymLinks — переходить по символическим ссылкам, Indexes — отображать содержимое каталога если нет файла индекса.

Require — устанавливает, какие пользователи имеют доступ к этому каталогу. Require all denied — всем запретить, Require all granted — всем разрешить. можно использовать вместо all директиву user или group чтобы явно указать пользователя.

Order — позволяет управлять доступом к директории. Принимает два значения Allow,Deny — разрешить для всех, кроме указанных или Deny,Allow — запретить для всех, кроме указанных. Теперь мы можем запретить доступ к директории для всех: Deny from all, а затем разрешить только для приложения от losst.ru: Allow from losst.ru.

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

У нас остался файл /etc/apache2/ports.conf:

В нем только одна директива, Listen, которая указывает программе на каком порту нужно работать.

Последний файл /etc/apache2/envvars, его вы вряд ли будете использовать, в нем указанны переменные, которые можно использовать в других конфигурационных файлах.

Дальше поговорим немного о htacess. Совсем немного.

Шаг 5. Настройка редиректа

Чтобы все запросы по http автоматически перенаправлялись на https, необходимо настроить перенаправление (redirect). Есть несколько способов это сделать.

В конфигурационном файле

Открываем файл с настройкой виртуальных доменов (как в шаге 3) и дописываем следующее:

<VirtualHost *:80>
    ServerName site.ru
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} 
</VirtualHost>

* в конкретном примере, мы перенаправили все запросы для сайта site.ru.
** обратите особое внимание, что если у Вас уже есть VirtualHost *:80 для настраиваемого сайта, необходимо его закомментировать или отредактировать

Установка модуля rewrite

Чтобы перенаправление работало в Apache, необходимо установить модуль rewrite.

а) в CentOS открываем конфигурационный файл и проверяем наличие строки:

vi /etc/httpd/conf.modules.d/00-base.conf

LoadModule rewrite_module modules/mod_rewrite.so

* если ее нет, добавляем; если она закомментирована, снимаем комментарий. 

systemctl restart httpd

б) в Ubuntu:

a2enmod rewrite

systemctl restart apache2

Configuring your server to permit SSI

To permit SSI on your server, you must have the following
directive either in your file, or in a
file:

Options +Includes

This tells Apache that you want to permit files to be parsed
for SSI directives. Note that most configurations contain
multiple directives
that can override each other. You will probably need to apply the
to the specific directory where you want SSI
enabled in order to assure that it gets evaluated last.

Not just any file is parsed for SSI directives. You have to
tell Apache which files should be parsed. There are two ways to
do this. You can tell Apache to parse any file with a
particular file extension, such as , with
the following directives:

AddType text/html .shtml
AddOutputFilter INCLUDES .shtml

One disadvantage to this approach is that if you wanted to
add SSI directives to an existing page, you would have to
change the name of that page, and all links to that page, in
order to give it a extension, so that those
directives would be executed.

The other method is to use the directive:

XBitHack on

tells Apache to parse files for SSI
directives if they have the execute bit set. So, to add SSI
directives to an existing page, rather than having to change
the file name, you would just need to make the file executable
using .

A brief comment about what not to do. You’ll occasionally
see people recommending that you just tell Apache to parse all
files for SSI, so that you don’t have to
mess with file names. These folks have
perhaps not heard about . The thing to
keep in mind is that, by doing this, you’re requiring that
Apache read through every single file that it sends out to
clients, even if they don’t contain any SSI directives. This
can slow things down quite a bit, and is not a good idea.

Of course, on Windows, there is no such thing as an execute
bit to set, so that limits your options a little.

In its default configuration, Apache does not send the last
modified date or content length HTTP headers on SSI pages,
because these values are difficult to calculate for dynamic
content. This can prevent your document from being cached, and
result in slower perceived client performance. There are two
ways to solve this:

Using Name-based Virtual Hosts

The first step is to create a block for
each different host that you would like to serve. Inside each block, you will need at minimum a
directive to designate
which host is served and a
directive to show where in the filesystem the content for that host
lives.

Main host goes away

Any request that doesn’t match an existing is handled by the global
server configuration, regardless of the hostname or ServerName.

When you add a name-based virtual host to an existing server, and
the virtual host arguments match preexisting IP and port combinations,
requests will now be handled by an explicit virtual host. In this case,
it’s usually wise to create a
with a matching that of
the base server. New domains on the same interface and port, but
requiring separate configurations, can then be added as subsequent (non-default)
virtual hosts.

ServerName inheritance

It is best to always explicitly list a in every name-based virtual host.

If a doesn’t specify
a , a server name will be
inherited from the base server configuration. If no server name was
specified globally, one is detected at startup through reverse DNS resolution
of the first listening address. In either case, this inherited server name
will influence name-based virtual host resolution, so it is best to always
explicitly list a in every
name-based virtual host.

For example, suppose that you are serving the domain
and you wish to add the virtual host
, which points at the same IP address.
Then you simply add the following to :

<VirtualHost *:80>
    # This first-listed virtual host is also the default for *:80
    ServerName www.example.com
    ServerAlias example.com 
    DocumentRoot "/www/domain"
</VirtualHost>

<VirtualHost *:80>
    ServerName other.example.com
    DocumentRoot "/www/otherdomain"
</VirtualHost>

You can alternatively specify an explicit IP address in place of the
in directives. For example, you might want to do this
in order to run some name-based virtual hosts on one IP address, and either
IP-based, or another set of name-based virtual hosts on another address.

Many servers want to be accessible by more than one name. This is
possible with the
directive, placed inside the section. For example in the first block above, the
directive indicates that
the listed names are other names which people can use to see that same
web site:

ServerAlias example.com *.example.com

then requests for all hosts in the domain will
be served by the virtual host. The wildcard
characters and can be used to match names.
Of course, you can’t just make up names and place them in or . You must
first have your DNS server properly configured to map those names to an IP
address associated with your server.

Name-based virtual hosts for the best-matching set of s are processed
in the order they appear in the configuration. The first matching or is used, with no different precedence for wildcards
(nor for ServerName vs. ServerAlias).

The complete list of names in the
directive are treated just like a (non wildcard)
.

Установка Apache на компьютер

Если вы хотите самостоятельно попробовать Apache, организовав полноценно работающий сайт с веб-сервером, базой данных и другими компонентами, воспользуйтесь информацией, предоставленной на официальном сайте. Там вы найдете все необходимые файлы для Windows, архивы и команды инсталляции для Linux, а также объяснения всех тонкостей, связанных с настройкой данного компонента.

Кстати, на «Комьюнити» есть отдельная инструкция, посвященная тому, как использовать Apache в качестве обратного прокси на Ubuntu. Это полезный материал для всех тех, кто хочет узнать больше о расширенных возможностях этого веб-сервера.

Подробнее: Как использовать Apache в качестве обратного прокси при помощи mod_proxy на Ubuntu 16.04

ШАГ 2 настройка Apache

Все конфигурационные файлы WEB сервера Apache данной сборки расположены в каталоге /Apache24/conf. Главным конфигом является файл /Apache24/conf/httpd.conf.

Для успешного запуска Apache, необходимо выполнить всего одну настройку в httpd.conf конфиге сервера, в строке №38, указать директиву ServerRoot, которая определяет путь к домашней директории вашей инсталляции Apache.

Указание ServerRoot

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

Define SRVROOT "Z:/WebDevelopment/Apache24"
ServerRoot "${SRVROOT}"

здесь в httpd.conf задание ServerRoot выполнено не напрямую, а через определение переменной SRVROOT. Это удобный способ, т.к. позволяет задавать путь единожды в начале конфига, а далее он будет уже применяться автоматически в нужных местах конфигурации через эту переменную.

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

Детали по конфигам Apache вы можете посмотреть в статьях «Обзор конфигурации Apache в Ubuntu» и «Главный config WEB сервера Apache в Ubuntu», т.к. вся логика, приемы настройки и значения директив будут в данном случае одинаковые как для конфигурации Apache на Windows, так и на Linux.

Apache на Windows

Apache — наиболее распространенный WEB сервер, который используется на многих хостингах и платформах и прекрасно справляется со своими обязанности для мелких и средних проектов и WEB сайтов. Так же, Apache поддерживается практически всеми хостинг провайдерами и часто предоставляется уже преднастроенным пользователю. Apache является открытым программным обеспечением, не требует платы за использование и очень хорошо сочетается с PHP языком программирования, CMS и сайтами, написанными на PHP, за счет встроенной поддержки и интеграции с PHP,  т.к. Apache, в первую очередь, предназначен для отдачи динамического содержимого. Долгое сотрудничество Apache и PHP делает связку WEB сервера Apache с языком программирования PHP отлаженной, проверенной временем и хорошо настраиваемой платформой для веб приложений, базирующихся на PHP. Многие, достаточно крупные WEB проекты используют именно Apache в связке с PHP CMS. Особенно привлекает в Apache его доступность и простота, в сочетании с большой гибкостью и функциональностью, наличие огромного количества документации и примеров по его настройке и эксплуатации.

Несмотря на то, что Apache преимущественно используется на Unix и Linux системах он, с тем же успехом и без потери в функциональности, может использоваться и на Windows. Использовать Apache на Windows можно как для WEB разработки, так и для полноценного хостинга сайтов на PHP CMS. Однако, на мой взгляд, наиболее удобно использовать Apache на Windows именно тем, кто ведет PHP веб разработку и тестирование CMS и при этом работает на Windows. Например, если вы постоянно работает на Windows, но вам нужно развернуть и протестировать сайт на PHP CMS, например, WordPress, Joomla или Yii.

В таком случае у вас есть несколько выборов:

• виртуальная машина VM с Linux, что затратно по времени развертывания и потреблению ресурсов системы;
• различные сборки Win+AMP;
• самостоятельно установить все необходимы компоненты Apache, MySQL, PHP на Windows  и настроить, как если бы это было на Linux.
• Больше вариантов смотри в статье: «Как организовать среду для web разработки»

Использовать виртуальную машину с Linux это очень хороший вариант, но он не всегда удобен, т.к. сама по себе, работающая VM, будет забирать у вашей системы ресурсы, и при слабом железе вы столкнетесь с тормозами, что не добавить комфорта в работе. Так же, нужно будет полностью настроить Linux на VM как WEB сервер. Однако если ваш PC достаточно мощный для такого варианта, то такой подход будет, все же, лучшим решением.

Вариант использования уже готовых сборок Win+AMP тоже не лишен недостатков. Главный недостаток таких сборок в том, что они предлагают свою систему конфигурации Apache, MySQL и PHP, которая часто сильно отличается от нормального подхода при настройке Apache на реальном Linux сервере. Поэтому эти сборки, предлагая вроде бы как облегчение в конфигурации Apache, на самом же деле еще больше запутывают и ломают стандартный поход к конфигурации WEB сервера. Еще одни из недостатков готовых сборок Win+AMP — это привязанность к сайту разработчиков этих сборок, необходимость регистрироваться для получения дополнительных компонентов, а иногда и делать оплату или терпеть рекламу. И самое главное в том, что работая с такими сборками, трудно получить правильное представление о настройке Apache, MySQL и PHP, как это выполнялось бы на реальном Linux сервере. Соответственно, когда придется настраивать Apache и другие компоненты LAMP на реальном Linux сервере, придется заново переучиваться уже на правильные методы и подходы настройки и конфигурации Apache и других компонентов LAMP путем внесения изменений в конфигурационные файлы.

Что делать, если нет желания вникать в системы конфигурации этих сборок, a хочется настраивать и использовать web сервер Apache точно так же, как это делается на Linux сервере, т.е. использовать правильный и естественный подход правки конфигурационных файлов. Именно в этой ситуации, когда вы хотите работать с Apache на Windows точно так же, как и на Linux, самостоятельная, отдельная установка Apache и будет полезна и целесообразна, тем более, что делается это достаточно легко и стандартно, а настройка выполнятся точно также как на Linux сервере.

Как добавить поддержку PHP как обработчика сценариев в Apache на Ubuntu или Windows детально описано в статье Установка PHP7 на Windows в разделе Настройка .

Web Site Content

Web site content can take many different forms, but may be broadly
divided into static and dynamic content.

Static content is things like HTML files, image files, CSS files,
and other files that reside in the filesystem. The directive specifies where in your
filesystem you should place these files. This directive is either set
globally, or per virtual host. Look in your configuration file(s) to
determine how this is set for your server.

Typically, a document called will be served
when a directory is requested without a file name being specified. For
example, if is set to
and a request is made for
, the file
will be served to the
client.

Dynamic content is anything that is generated at request
time, and may change from one request to another. There are numerous
ways that dynamic content may be generated. Various handlers are available to generate content. CGI programs may be written to generate
content for your site.

ШАГ 4 инсталляция Apache как службы Windows

Приведенный выше способ запуска и остановки web сервера Apache прекрасно работает и им можно с успехом пользоваться, создав ярлык на исполняемый файл httpd.exe или написав .bat файлы с командами старта и остановки сервера. Однако более удобным вариантом будет использование Apache как системной службы Windows, что позволит запускать и останавливать Apache в автоматическом, полуавтоматическом режимах и вручную. Для этих действий можно будет использовать утилиту управления Apache службой Apache24\bin\ApacheMonitor.exe, которая входит в данный дистрибутив Apache. ApacheMonitor.exe это маленькая утилита, представлявшая собой оконную программку, висящую в системном трее и позволяющую выполнять запуск и остановку службы Apache и контролировать ее состояние. Такой подход дает некоторое удобство в работе с web сервером Apache как системной службой Windows. Поэтому, далее будут рассмотрены необходимые действия для установки Apache как системной службы Windows.

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

>Z:\WebDevelopment\Apache24\bin\httpd help

или, находясь в каталоге с бинарниками Apache:

>httpd -h

и в консоли будет выведен краткий help по доступным командам Apache и их синтаксис:

>httpd -h

Usage: httpd   
              
               
              
                     
Options:
  -D name            : define a name for use in  directives
  -d directory       : specify an alternate initial ServerRoot
  -f file            : specify an alternate ServerConfigFile
  -C "directive"     : process directive before reading config files
  -c "directive"     : process directive after reading config files
  -n name            : set service name and use its ServerConfigFile and ServerRoot
  -k start           : tell Apache to start
  -k restart         : tell running Apache to do a graceful restart
  -k stop|shutdown   : tell running Apache to shutdown
  -k install         : install an Apache service
  -k config          : change startup Options of an Apache service
  -k uninstall       : uninstall an Apache service
  -w                 : hold open the console window on error
  -e level           : show startup errors of level (see LogLevel)
  -E file            : log startup errors to file
  -v                 : show version number
  -V                 : show compile settings
  -h                 : list available command line options (this page)
  -l                 : list compiled in modules
  -L                 : list available configuration directives
  -t -D DUMP_VHOSTS  : show parsed vhost settings
  -t -D DUMP_RUN_CFG : show parsed run settings
  -S                 : a synonym for -t -D DUMP_VHOSTS -D DUMP_RUN_CFG
  -t -D DUMP_MODULES : show all loaded modules
  -M                 : a synonym for -t -D DUMP_MODULES
  -t -D DUMP_INCLUDES: show all included configuration files
  -t                 : run syntax check for config files
  -T                 : start without DocumentRoot(s) check
  -X                 : debug mode (only one worker, do not detach)

Рекомендация: используйте с данными командами полный путь до файла httpd.exe как в примерах ниже.

Для инсталляции Apache как системной службы Windows нужно выполнить в консоли команду:

>Z:\WebDevelopment\Apache24\bin\httpd.exe -k install

Для деинсталяции Apache как системной службы Windows нужно выполнить в консоли команду:

>Z:\WebDevelopment\Apache24\bin\httpd.exe -k uninstall

После установки Apache в качестве системной службы Windows вы можете настроить работу этой службы стандартным для всех служб Windows способом в Консоли управления Microsoft — оснастке services.msc запустив ее в cmd.exe командой:

>services.msc

или воспользовавшись другими стандартными способами:

• Меню Пуск, в строке поиска наберите services.msc и нажмите клавишу Enter;
• Нажмите сочетание клавиш Win+R, наберите services.msc и нажмите клавишу Enter;
• Через оконный интерфейс по пути: Пуск->Панель управления->Администрирование->Службы

Установленная служба Apache будет иметь:

• название: Apache2.4;
• описание: Apache/2.4.23 (Win64) OpenSSL/1.0.2j;
• тип запуска: Автоматически.

Настройте необходимый вам вариант запуска службы стандартным способом.

Так же, для управления службой Apache2.4 вы можете воспользоваться описанной выше программой из дистрибутива сервера Apache24\bin\ApacheMonitor.exe. Для этого запустите указанный файл ApacheMonitor.exe и воспользуйтесь для запуска или остановки Apache кнопками в окне данной программы. В свернутом состоянии эта программа ‘висит’ в системном трее в виде иконки состояния службы Apache и может быть от туда вызвана.

Скриншот запущенной программы ApacheMonitor.exe

На этом Portable инсталляция Apache на Windows из zip архива закончена, далее можно приступать к индивидуальной настройке web сервера и организации виртуальных хостов.

Смотри также:

Еще, дополнительно, о настройке можно почитать на сайте Apache: .

Настройка web-сервера Apache2 в ALD

Для обеспечения совместной работы web-сервера Apache 2.2 с ALD необходимо:

– наличие в системе, на которой функционирует web-сервер, установленного пакета клиента ALD — ; – разрешение имен должно быть настроено таким образом, чтобы имя системы разрешалось, в первую очередь, как полное имя (например, ); – клиент ALD должен быть настроен на используемый ALD домен; – в системе должен быть установлен модуль web-сервера Apache 2.2 auth_kerb из пакета .

Наличие модуля web-сервера Apache 2.2 auth_kerb предоставляет возможность организации совместной работы с ALD с использованием для аутентификации пользователей посредством Kerberos метода GSSAPI. Для проведения операций по настройке ALD и администрированию Kerberos необходимо знание паролей администраторов ALD и Kerberos. Для обеспечения возможности работы web-сервера Apache 2.2 с ALD необходимо:

активировать модуль web-сервера Apache 2.2 auth_kerb при помощи команды:

в конфигурационных файлах виртуальных хостов web-сервера Apache 2.2 для областей, требующих авторизации, указать:

создать в БД ALD с помощью утилиты администрирования ALD принципала, соответствующего настраиваемому web-серверу Apache. Принципал создается с автоматически сгенерированным случайным ключом:

ввести созданного принципала в группу сервисов mac, используя следующую команду:

создать файл ключа Kerberos для web-сервера Apache с помощью утилиты администрирования ALD ald-client, используя следующую команду:

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

сменить владельца полученного на предыдущем шаге файла keytab на пользователя www-data, выполнив следующую команду:

сделать файл доступным на чтение для остальных пользователей:

перезапустить web-сервер Apache, выполнив команду:

Браузер пользователя должен поддерживать аутентификацию negotiate. В последних версиях браузера Konqueror данная поддержка присутствует автоматически. В браузере Mozilla Firefox в настройках, доступных по адресу about:config, необходимо указать, для каких серверов доступна аутентификация negotiate. Для выполнения данной настройки необходимо задать маски доменов или в общем случае http- и https- соединения в качестве значений параметра , вставив, например, значение .