Введение в apache

Early Hints

An alternative to PUSHing resources is to send headers to the
client before the response is even ready. This uses the HTTP feature called «Early Hints» and
is described in RFC 8297.

In order to use this, you need to explicitly enable it on the server via

H2EarlyHints on

(It is not enabled by default since some older browser tripped on such responses.)

If this feature is on, you can use the directive to
trigger early hints and resource PUSHes:

<Location /xxx.html>
    H2PushResource /xxx.css
    H2PushResource /xxx.js
</Location>

This will send out a response to a client as soon
as the server starts processing the request. This may be much early than
the time the first response headers have been determined, depending on your web
application.

Overview for the impatient

Installing on Fedora/CentOS/Red Hat Enterprise Linux

Введение в объектно-ориентированные базы данных

sudo yum install httpd
sudo systemctl enable httpd
sudo systemctl start httpd

Newer releases of these distros use
rather than . See the
Fedora project’s documentation for platform-specific notes.

Installing on Ubuntu/Debian

sudo apt install apache2
sudo service apache2 start

See Ubuntu’s documentation for platform-specific notes.

Installing from source

	Download the latest release from

NN must be replaced with the current version
number, and PREFIX must be replaced with the
filesystem path under which the server should be installed. If
PREFIX is not specified, it defaults to
.

Each section of the compilation and installation process is
described in more detail below, beginning with the requirements
for compiling and installing Apache httpd.

Running several name-based web sites on a single IP address.

Your server has multiple hostnames that resolve to a single address,
and you want to respond differently for
and .

Note

Creating virtual
host configurations on your Apache server does not magically
cause DNS entries to be created for those host names. You
must have the names in DNS, resolving to your IP
address, or nobody else will be able to see your web site. You
can put entries in your file for local
testing, but that will work only from the machine with those
entries.

# Ensure that Apache listens on port 80
Listen 80
<VirtualHost *:80>
    DocumentRoot "/www/example1"
    ServerName www.example.com

    # Other directives here
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot "/www/example2"
    ServerName www.example.org

    # Other directives here
</VirtualHost>

The asterisks match all addresses, so the main server serves no
requests. Due to the fact that the virtual host with
is first
in the configuration file, it has the highest priority and can be seen
as the default or primary server. That means
that if a request is received that does not match one of the specified
directives, it will be served by this first
.

The above configuration is what you will want to use in almost
all name-based virtual hosting situations. The only thing that this
configuration will not work for, in fact, is when you are serving
different content based on differing IP addresses or ports.

Оптимизация размещения файловых областей

Сразу после установки структура папок программного пакета Apache выглядит следующим образом:

bin

— исполняемые файлы Web-сервера.

cgi-bin

— CGI-сценарии Web-сайта.

conf

— конфигурационные файлы Web-сервера.

error

— страницы ошибок протокола HTTP.

htdocs

— файловая область Web-сайта (проще говоря, здесь размещается Web-сайт).

icons

— пиктограммы Web-сервера

include

— подключаемые файлы заголовков (h-файлы), небоходимы при сборке Web-сервера компилятором VC.

lib

— библиотечные файлы Web-сервера.

logs

— журналы работы Web-сервера.

manuals

— документация в формате HTML.

modules

— дополнительные программные модули Web-сервера (so-файлы).

Из перечисленных выше папок четырём (cgi-bin, conf, htdocs и logs) не место в базовой папке Web-сервера. Из нужно скопировать в рабочую папку Web-сайта: «D:\www». Исходные папки можно было бы удалить, однако они могут понадобится для восстановления начальной ситуации, если в ходе настройки Web-сервера что-то пойдёт не так. С другой стороны, если их оставить на прежнем месте, то из-за неполной настройки Web-сервера может случиться так, что использоваться будут именно эти папки, а не те, которые мы хотим. Поэтому после копирования их лучше просто переименовать в cgi-bin.0, conf.0, htdocs.0 и logs.0 соответственно.

Сервер 1С:Предприятие на Ubuntu 16.04 и PostgreSQL 9.6, для тех, кто хочет узнать его вкус. Рецепт от Капитана

Если кратко описать мое отношение к Postgres: Использовал до того, как это стало мейнстримом.
Конкретнее: Собирал на нем сервера для компаний среднего размера (до 50 активных пользователей 1С).
На настоящий момент их набирается уже больше, чем пальцев рук пары человек (нормальных, а не фрезеровщиков).
Следуя этой статье вы сможете себе собрать такой же и начать спокойную легальную жизнь, максимально легко сделать первый шаг в мир Linux и Postgres.
А я побороться за 1. Лучший бизнес-кейс (лучший опыт автоматизации предприятия на базе PostgreSQL).
Если, конечно, статья придется вам по вкусу.

Как работает Apache

Основная
роль Apache связана с коммуникацией по сетям и использует протокол TCP / IP
(протокол управления передачей / интернет-протокол, который позволяет
устройствам с IP-адресами в одной сети взаимодействовать друг с другом).

Сервер
Apache настроен для работы через файлы конфигурации, в которые добавляются
директивы для управления его поведением. В
своем состоянии ожидания Apache прослушивает IP-адреса, указанные в его файле
конфигурации (HTTPd.conf). Всякий раз, когда он получает запрос, он анализирует
заголовки, применяет правила, указанные для него в файле Config, и принимает
меры.

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

Поскольку
IP-адреса трудно запомнить, мы, как посетители определенных сайтов, обычно
вводим соответствующие им имена доменов в поле URL-адреса в наших браузерах. Затем
браузер подключается к DNS-серверу, который переводит имена доменов на их
IP-адреса. Затем
браузер берет возвращаемый IP-адрес и подключается к нему.  Браузер
также отправляет Host header с запросом, чтобы, если сервер размещает несколько сайтов, он будет знать, какой из них должен обслуживать.

Например, ввод текста на www.google.com в поле адреса вашего
браузера может отправить следующий запрос на сервер по этому IP-адресу:

Первая
строка содержит несколько фрагментов информации.  Во-первых, существует метод (в данном случае это GET), URI,
который указывает, какую страницу нужно извлечь или какую программу нужно
запустить (в этом случае это корневой каталог, обозначенный /), и, наконец,
есть HTTP-версия (которая в данном случае является HTTP 1.1).

HTTP —
это протокол без ответа. Это
набор правил, регулирующих связь между клиентом и сервером. Клиент
(обычно, но не обязательно веб-браузер) делает запрос, сервер отправляет ответ,
а связь прекращается. Сервер
не ожидает дополнительной связи, как в случае с другими протоколами, которые
остаются в состоянии ожидания после завершения запроса.

Если
запрос выполнен успешно, сервер возвращает код состояния 200 (что означает, что
страница найдена), заголовки ответов вместе с запрошенными данными.  .
Заголовок ответа сервера Apache может выглядеть примерно так:

Первая
строка в заголовке ответа — это строка состояния.  Он
содержит версию HTTP и код состояния. Далее следует дата, а затем некоторая информация о хост-сервере и извлеченных
данных.  Заголовок  позволяет клиенту узнать тип извлеченных данных, чтобы он знал, как его обрабатывать. клиент знает размер тела ответа. Если
запрос не пошел, клиент получит код ошибки и сообщение, например, следующий
заголовок ответа в случае ошибки страницы, не найденной:

Running Apache as a Console Application

Running Apache as a service is usually the recommended way to
use it, but it is sometimes easier to work from the command line,
especially during initial configuration and testing.

To run Apache from the command line as a console application,
use the following command:

Apache will execute, and will remain running until it is stopped
by pressing Control-C.

You can also run Apache via the shortcut Start Apache in Console
placed to during the installation.
This will open a console window and start Apache inside it. If you
don’t have Apache installed as a service, the window will remain
visible until you stop Apache by pressing Control-C in the console
window where Apache is running in. The server will exit in a few
seconds. However, if you do have Apache installed as a service, the
shortcut starts the service. If the Apache service is running
already, the shortcut doesn’t do anything.

If Apache is running as a service, you can tell it to stop by opening another console
window and entering:

Running as a service should be preferred over running in a
console window because this lets Apache end any current operations
and clean up gracefully.

But if the server is running in a console window, you can
only stop it by pressing Control-C in the same window.

You can also tell Apache to restart. This forces it to reread
the configuration file. Any operations in progress are allowed to
complete without interruption. To restart Apache, either press
Control-Break in the console window you used for starting Apache,
or enter

if the server is running as a service.

Note for people familiar with the Unix version of Apache:
these commands provide a Windows equivalent to and . The
command line option used, , was chosen as a reminder
of the command used on Unix.

If the Apache console window closes immediately or unexpectedly
after startup, open the Command Prompt from the Start Menu —>
Programs. Change to the folder to which you installed Apache, type
the command , and read the error message. Then
change to the logs folder, and review the
file for configuration mistakes. Assuming httpd was installed into
,
you can do the following:

Then wait for Apache to stop, or press Control-C. Then enter the
following:

When working with Apache it is important to know how it will
find the configuration file. You can specify a configuration file
on the command line in two ways:

• specifies an absolute or relative path to
  a particular configuration file:

  or

• specifies the installed Apache service
  whose configuration file is to be used:

In both of these cases, the proper
should be set in
the configuration file.

If you don’t specify a configuration file with
or , Apache will use the file name compiled into the
server, such as . This built-in path
is relative to the installation directory. You can verify the compiled
file name from a value labelled as when
invoking Apache with the switch, like this:

Apache will then try to determine its by trying the following, in this order:

1. A directive
   via the command line switch.
2. The switch on the command line.
3. Current working directory.
4. A registry entry which was created if you did a binary
   installation.
5. The server root compiled into the server. This is by default, you can verify it by using and looking for a value labelled as
   .

If you did not do a binary install, Apache will in some
scenarios complain about the missing registry key. This warning can
be ignored if the server was otherwise able to find its
configuration file.

Introduction

In order to stop or restart the Apache HTTP Server, you must send a signal to
the running processes. There are two ways to
send the signals. First, you can use the unix
command to directly send signals to the processes. You will
notice many executables running on your system,
but you should not send signals to any of them except the parent,
whose pid is in the . That is to say you
shouldn’t ever need to send signals to any process except the
parent. There are four signals that you can send the parent:
,
,
, and
, which
will be described in a moment.

To send a signal to the parent you should issue a command
such as:

The second method of signaling the processes
is to use the command line options: ,
, and ,
as described below. These are arguments to the binary, but we recommend that
you send them using the control script, which
will pass them through to .

After you have signaled , you can read about
its progress by issuing:

Using _default_ vhosts

vhosts
for all ports

Catching every request to any unspecified IP address and
port, i.e., an address/port combination that is not used for
any other virtual host.

<VirtualHost _default_:*>
    DocumentRoot "/www/default"
</VirtualHost>

Using such a default vhost with a wildcard port effectively prevents
any request going to the main server.

A default vhost never serves a request that was sent to an
address/port that is used for name-based vhosts. If the request
contained an unknown or no header it is always
served from the primary name-based vhost (the vhost for that
address/port appearing first in the configuration file).

You can use or
to rewrite any
request to a single information page (or script).

vhosts
for different ports

Same as setup 1, but the server listens on several ports and we want
to use a second vhost for port 80.

<VirtualHost _default_:80>
    DocumentRoot "/www/default80"
    # ...
</VirtualHost>

<VirtualHost _default_:*>
    DocumentRoot "/www/default"
    # ...
</VirtualHost>

The default vhost for port 80 (which must appear before any
default vhost with a wildcard port) catches all requests that were sent
to an unspecified IP address. The main server is never used to serve a
request.

vhosts
for one port

We want to have a default vhost for port 80, but no other default
vhosts.

<VirtualHost _default_:80>
    DocumentRoot "/www/default"
...
</VirtualHost>

A request to an unspecified address on port 80 is served from the
default vhost. Any other request to an unspecified address and port is
served from the main server.

Ускорение работы 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 секунд. Но лучше держать это значение минимальным. Это позволяет предотвратить излишнее расходование ресурсов.

Using the ServerPath directive

We have a server with two name-based vhosts. In order to match the
correct virtual host a client must send the correct
header. Old HTTP/1.0 clients do not send such a header and Apache has
no clue what vhost the client tried to reach (and serves the request
from the primary vhost). To provide as much backward compatibility as
possible we create a primary vhost which returns a single page
containing links with an URL prefix to the name-based virtual
hosts.

<VirtualHost 172.20.30.40>
    # primary vhost
    DocumentRoot "/www/subdomain"
    RewriteEngine On
    RewriteRule "." "/www/subdomain/index.html"
    # ...
</VirtualHost>

<VirtualHost 172.20.30.40>
    DocumentRoot "/www/subdomain/sub1"
    ServerName www.sub1.domain.tld
    ServerPath "/sub1/"
    RewriteEngine On
    RewriteRule "^(/sub1/.*)" "/www/subdomain$1"
    # ...
</VirtualHost>

<VirtualHost 172.20.30.40>
    DocumentRoot "/www/subdomain/sub2"
    ServerName www.sub2.domain.tld
    ServerPath "/sub2/"
    RewriteEngine On
    RewriteRule "^(/sub2/.*)" "/www/subdomain$1"
    # ...
</VirtualHost>

Due to the
directive a request to the URL
is always served
from the sub1-vhost. A request to the URL
is only
served from the sub1-vhost if the client sent a correct
header. If no header is sent the
client gets the information page from the primary host.

Please note that there is one oddity: A request to
is also served from the
sub1-vhost if the client sent no header.

Types of Configuration Section Containers

There are two basic types of containers. Most containers are
evaluated for each request. The enclosed directives are applied only
for those requests that match the containers. The , , and

containers, on the other hand, are evaluated only at server startup
and restart. If their conditions are true at startup, then the
enclosed directives will apply to all requests. If the conditions are
not true, the enclosed directives will be ignored.

The directive
encloses directives that will only be applied if an appropriate
parameter is defined on the command line. For example,
with the following configuration, all requests will be redirected
to another site only if the server is started using
:

<IfDefine ClosedForNow>
    Redirect "/" "http://otherserver.example.com/"
</IfDefine>

The
directive is very similar, except it encloses directives that will
only be applied if a particular module is available in the server.
The module must either be statically compiled in the server, or it
must be dynamically compiled and its line must be earlier in the
configuration file. This directive should only be used if you need
your configuration file to work whether or not certain modules are
installed. It should not be used to enclose directives that you want
to work all the time, because it can suppress useful error messages
about missing modules.

In the following example, the directive will be
applied only if is available.

<IfModule mod_mime_magic.c>
    MimeMagicFile "conf/magic"
</IfModule>

The
directive is very similar to and , except it encloses directives that will
only be applied if a particular version of the server is executing. This
module is designed for the use in test suites and large networks which have to
deal with different httpd versions and different configurations.

<IfVersion >= 2.4>
    # this happens only in versions greater or
    # equal 2.4.0.
</IfVersion>

Проблема установки Apache под Windows

Основная проблема установки Web-сервера Apache под Windows заключается в том, что после первичной установки дистрибутива весь пакет (исполняемые программы, конфигурационные файлы, файлы журналов работы сервера и файловая область для размещения Web-страниц) размещается в одном месте. Это мешает нормальной эксплуатации продукта по следующим причинам:

• Разграничение прав доступа. Исполняемые файлы должны оставаться неизменными, конфигурационными файлами управляет администратор Web-сервера, а доступ к файловой области Web-страниц должны иметь разработчики и администраторы сайта. Права доступа к папке «Program Files» настроены в предположении, что в ней хранятся исполняемые модули программных пакетов, модификация которых не требуется.
• Захламление системных папок. Папка «Program Files» операционной системы Windows изначально предназначена для размещения только исполняемых файлов. Она может находиться на отдельном томе, размер которого выбирается системным администратором в предположении о его относительном постоянстве. Уж точно никто не ожидает, что в этой папке будут храниться пользовательские данные, галереи рисунков и файловый архив сайта.

Поэтому установка Apache под Windows должна проводиться в два этапа:

1. Первичная установка программного пакета в выбранную папку.
2. Оптимизация размещения файловых областей web-сервера и соответствующее изменение его конфигурации.

При модификации конфигурационных файлов Apache нужно постоянно помнить, что в качестве разделителя путей к файлам и папкам должен использоваться символ «прямой слеш», как в операционных системах Unix и Linux, а не «обратный слеш», как в Windows.

Разные серверы для статического и динамического контента

Процессы Apache, которые управляют динамическим контентом, потребляют от 3 до 20 Мб памяти. Статический контент требуют всего лишь 1Мб памяти. Процесс, управляющий динамическим контентом, при следующем запросе может предоставлять статический контент.

Что приводит к расходам памяти и замедлению работы сервера. Поэтому рекомендуется разделить серверы на управляющие статическим контентом и динамическим контентом.

Например, можно использовать небольшой Apache в качестве frontend-сервера, предоставляющего статический контент. Запросы на динамический контент будут перенаправляться к другому серверу Apache со всеми необходимыми модулями.

Для подобного перенаправления запросов используются модули mod_proxy и mod_rewrite. Клиент не заметит разницы, и будет считать, что все запросы выполняются одним сервером.

Используя два сервера, можно ускорить работу Apache, выдавая статический контент быстрее и выделяя большее количество памяти для обработки динамического контента.

Testing the Installation ¶

After starting Apache (either in a console window or as a
service) it will be listening on port 80 (unless you changed the
directive in the
configuration files or installed Apache only for the current user).
To connect to the server and access the default page, launch a
browser and enter this URL:

Apache should respond with a welcome page and you should see
«It Works!». If nothing happens or you get an error, look in the
file in the subdirectory.
If your host is not connected to the net, or if you have serious
problems with your DNS (Domain Name Service) configuration, you
may have to use this URL:

If you happen to be running Apache on an alternate port, you
need to explicitly put that in the URL:

Once your basic installation is working, you should configure it
properly by editing the files in the subdirectory.
Again, if you change the configuration of the Windows NT service
for Apache, first attempt to start it from the command line to
make sure that the service starts with no errors.

История создания Apache

Apache — это сокращение от «a patchy server», что переводится как сервер с патчами. Такое название появилось из-за происхождения программы. Все началось с разработки веб-сервера CERN HTTPd и NCSA HTTPd в Национальном центре суперкомпьютерных приложений (NCSA). Позднее к проекту подключились другие авторы, которые стали накладывать свои патчи. Патч ― это информация, кусок кода или программный модуль, который исправляет недочёты разработчиков. Их ещё называют заплатки. В 1995 году Брайан Белендорф объединил все патчи и создал команду разработчиков, которая выпустила первую версию Apache. Релиз Apache 1.0 прошёл в декабре 1995 года, но популярной эта программа стала только через год. Далее группа разработчиков расширялась, и они создали Apache для различные операционные системы (Linux, BSD, Mac OS, Microsoft Windows, Novell NetWare, BeOS).

В 1998 году появилась версия Apache 1.3, а в 1999 году была создана некоммерческая организация Apache Software Foundation. В марте 2000 года состоялась первая конференция для разработчиков ApacheCon. На ней была представлена версия Apache 2.0. Она отличалась новой модульной структурой. Это предоставило широкие возможности для функционала программы. На данный момент последней версией является Apache 2.4.

Встречается в статьях

Инструкции:

1. Использование playbook и роли в Ansible на примере установки NGINX
2. Как настроить связку Apache + HTTP/2 на Linux CentOS 7
3. Как установить и настроить связку Asterisk + FreePBX на CentOS 8
4. Настройка веб-сервера на CentOS 7 со всем необходимым для правильной работы
5. Настройка веб-сервера на CentOS 8 со всем необходимым для правильной работы
6. Инструкция по установке и использованию GLPI на Linux CentOS
7. Как вручную настроить сервер хостинга на CentOS 7
8. Как установить и настроить iRedMail на Linux CentOS
9. Настройка почтового сервера iRedMail на Ubuntu
10. Установка и настройка кластера Kubernetes на Linux Ubuntu
11. Как настроить почту для корпоративной среды на CentOS 8
12. Как настроить почту для корпоративной среды на Ubuntu Server
13. Настройка веб-сервера на Ubuntu со всем необходимым для правильной работы
14. Как настроить почту на базе Postfix для корпоративной среды
15. Установка и настройка файлового сервера Samba на CentOS 8
16. Установка и настройка файлового сервера Samba на Ubuntu
17. Как установить и настроить прокси-сервер Squid на Ubuntu Server
18. Настройка портала TeamPass для совместного хранения паролей
19. Установка Nginx + PHP + MySQL на Astra Linux
20. Установка веб-сервера Apache на FreeBSD
21. Установка и настройка почтового сервера Zimbra на Linux
22. Как собрать свой собственный deb-пакетов с нуля под Linux Debian

Мини-инструкции:

1. Как пользоваться командой systemctl
2. Как установить и работать с Redis на сервере под управлением Linux Ubuntu
3. Установка и настройка memcached на CentOS 7 и 8
4. Установка и настройка XCache на CentOS 7
5. Настройка поддержки Firebird в PHP на CentOS и Ubuntu
6. Как настроить Apache для работы по HTTPS (SSL)
7. Как установить PHP 7 на Linux CentOS 7
8. Установка и базовая настройка vsFTPd на Ubuntu Server
9. Инструкция по установке и настройке PostfixAdmin на CentOS 7
10. Получение бесплатного сертификата Lets Encrypt
11. Настройка logrotate в примерах
12. Установка и настройка OwnCloud на CentOS 7 или 8
13. Xibo сервер на Linux Ubuntu — установка и настройка
14. Как управлять процессами в операционной системе Linux
15. Инструкция по установке и настройке phplist
16. Как и где настраивать время сессии PHP
17. Инструкция по переходу на новую версию GLPI
18. Как установить и настроить сервер Haproxy на Linux CentOS 7
19. Анализ и мониторинг нагрузки веб-сервера на базе Linux
20. Установка и настройка умного дома от MajorDoMo
21. Установка и настройка Nextcloud + NGINX на Ubuntu
22. Обновления портала базы знаний phpMyFAQ до последней версии
23. Инструкция по обновления веб-приложения phpMyAdmin на Linux
24. Установка и настройка SAMS для управления Squid на CentOS 7
25. Установка и настройка сервера Redmine + Apache + passenger
26. Установка панели управления ISPmanager на Ubuntu или CentOS
27. Использование Roundcube для нескольких почтовых серверов
28. Как создать свой собственный образ для Docker
29. Инструкция по развертыванию Nextcloud с Apache на Ubuntu
30. Добавление еще одной версии PHP в Apache на CentOS 7
31. Установка веб-интерфейса phpMyAdmin на CentOS для управления MySQL
32. Установка платформы .NET Framework на Linux Ubuntu
33. Установка и настройка сервера 1С + PostgreSQL на Linux Ubuntu
34. Настройка сервера видеоконференцсвязи OpenMeetings на Linux CentOS 8
35. Инструкция по установке и настройке phplist на Linux Ubuntu
36. Установка и настройка сервера NextCloud на CentOS 8
37. Установка и настройка модуля PageSpeed для NGINX и Apache
38. Установка и использование почтового клиента WebMail Lite на Linux CentOS
39. Настройка сервера мониторинга Zabbix 5 на Linux CentOS 8
40. Организация сервиса календаря и адресной книги на базе Baikal
41. Настройка аутентификации доменных пользователей в Nextcloud
42. Примеры настройки сервисов и их установки с помощью ролей в Ansible
43. Публикация баз 1С как веб-приложение в Apache на операционной системе Windows
44. Настройка Runner в GitLab CI/CD для загрузки изменений проекта на веб-серверы после коммита
45. Как установить веб-сервер Tomcat на Linux Ubuntu Server
46. Установка и настройка системы CI/CD Teamcity на Linux Ubuntu Server
47. Как настроить свой приватный репозиторий для хранения образов Docker
48. Как установить, настроить и подключиться к MongoDB на Linux Ubuntu

Migrating a name-based vhost to an IP-based vhost

The name-based vhost with the hostname
(from our example, setup 2) should get its own IP
address. To avoid problems with name servers or proxies who cached the
old IP address for the name-based vhost we want to provide both
variants during a migration phase.

The solution is easy, because we can simply add the new IP address
() to the
directive.

Listen 80
ServerName www.example.com
DocumentRoot "/www/example1"

<VirtualHost 172.20.30.40 172.20.30.50>
    DocumentRoot "/www/example2"
    ServerName www.example.org
    # ...
</VirtualHost>

<VirtualHost 172.20.30.40>
    DocumentRoot "/www/example3"
    ServerName www.example.net
    ServerAlias *.example.net
    # ...
</VirtualHost>