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

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

Инструкции:

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. Установка и настройка CRM Битрикс24 от 1С на Linux CentOS
32. Установка веб-интерфейса phpMyAdmin на CentOS для управления MySQL
33. Установка платформы .NET Framework на Linux Ubuntu
34. Установка и настройка сервера 1С + PostgreSQL на Linux Ubuntu
35. Настройка сервера видеоконференцсвязи OpenMeetings на Linux CentOS 8
36. Инструкция по установке и настройке phplist на Linux Ubuntu
37. Установка и настройка сервера NextCloud на CentOS 8
38. Установка и настройка модуля PageSpeed для NGINX и Apache
39. Установка и использование почтового клиента WebMail Lite на Linux CentOS
40. Настройка сервера мониторинга Zabbix 5 на Linux CentOS 8
41. Организация сервиса календаря и адресной книги на базе Baikal
42. Настройка аутентификации доменных пользователей в Nextcloud
43. Примеры настройки сервисов и их установки с помощью ролей в Ansible
44. Публикация баз 1С как веб-приложение в Apache на операционной системе Windows
45. Настройка Runner в GitLab CI/CD для загрузки изменений проекта на веб-серверы после коммита
46. Как установить веб-сервер Tomcat на Linux Ubuntu Server
47. Установка и настройка системы CI/CD Teamcity на Linux Ubuntu Server
48. Как настроить свой приватный репозиторий для хранения образов Docker
49. Как установить, настроить и подключиться к MongoDB на Linux Ubuntu
50. Шпаргалка по работе с системой управления конфигурациями Ansible
51. Как установить на CentOS и выполнить пробный запуск программы jmeter
52. Как установить несколько разных версий на Linux Ubuntu

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 в разделе Настройка .

Basic Configuration

When you have a built with you need some
basic configuration for it becoming active. The first thing, as with every Apache module,
is that you need to load it:

LoadModule http2_module modules/mod_http2.so

The second directive you need to add to your server configuration is

Protocols h2 http/1.1

This allows h2, the secure variant, to be the preferred protocol on your server
connections. When you want to enable all HTTP/2 variants, you simply write:

Protocols h2 h2c http/1.1

Depending on where you put this directive, it affects all connections or just
the ones to a certain virtual host. You can nest it, as in:

Protocols http/1.1
<VirtualHost ...>
    ServerName test.example.org
    Protocols h2 http/1.1
</VirtualHost>

This allows only HTTP/1 on connections, except SSL connections to
which offer HTTP/2.

Choose a strong SSLCipherSuite

The needs to be configured with
a strong TLS cipher suite. The current version of does not enforce any cipher but most
clients do so. Pointing a browser to a enabled server with a inappropriate
cipher suite will force it to simply refuse and fall back to HTTP 1.1. This is a common mistake
that is done while configuring httpd for HTTP/2 the first time, so please keep it in mind to avoid
long debugging sessions! If you want to be sure about the cipher suite to choose please avoid
the ones listed in the .

The order of protocols mentioned is also relevant. By default, the first one is the
most preferred protocol. When a client offers multiple choices, the one most to the
left is selected. In

Protocols http/1.1 h2

the most preferred protocol is HTTP/1 and it will always be selected unless a
client only supports h2. Since we want to talk HTTP/2 to clients that
support it, the better order is

Protocols h2 h2c http/1.1

There is one more thing to ordering: the client has its own preferences, too. If
you want, you can configure your server to select the protocol most preferred by
the client:

ProtocolsHonorOrder Off

makes the order you wrote the Protocols irrelevant and only the client’s
ordering will decide.

A last thing: the protocols you configure are not checked for correctness
or spelling. You can mention protocols that do not exist, so there is no need
to guard with any
checks.

Troubleshooting

When you put configuration directives in a
file, and you don’t get the desired effect, there are a number of
things that may be going wrong.

Most commonly, the problem is that is not
set such that your configuration directives are being honored. Make
sure that you don’t have a in effect
for the file scope in question. A good test for this is to put garbage
in your file and reload the page. If a server error is
not generated, then you almost certainly have in effect.

If, on the other hand, you are getting server errors when trying to
access documents, check your httpd error log. It will likely tell you
that the directive used in your file is not
permitted.

This will indicate either that you’ve used a directive that is
never permitted in files, or that you simply
don’t have set to
a level sufficient for the directive you’ve used. Consult the
documentation for that particular directive to determine which is
the case.

Alternately, it may tell you that you had a syntax error in your
usage of the directive itself.

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)
.

ШАГ 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.

How the server selects the proper name-based virtual host

It is important to recognize that the first step in name-based virtual
host resolution is IP-based resolution. Name-based virtual host
resolution only chooses the most appropriate name-based virtual host
after narrowing down the candidates to the best IP-based match. Using a wildcard (*)
for the IP address in all of the VirtualHost directives makes this
IP-based mapping irrelevant.

When a request arrives, the server will find the best (most specific) matching
argument based on
the IP address and port used by the request. If there is more than one virtual host
containing this best-match address and port combination, Apache will further
compare the and directives to the server name
present in the request.

If you omit the
directive from any name-based virtual host, the server will default
to a fully qualified domain name (FQDN) derived from the system hostname.
This implicitly set server name can lead to counter-intuitive virtual host
matching and is discouraged.

Name-based vs. IP-based Virtual Hosts

IP-based virtual hosts use the IP address of the connection to
determine the correct virtual host to serve. Therefore you need to
have a separate IP address for each host.

With name-based virtual hosting, the server relies on the client to
report the hostname as part of the HTTP headers. Using this technique,
many different hosts can share the same IP address.

Name-based virtual hosting is usually simpler, since you need
only configure your DNS server to map each hostname to the correct
IP address and then configure the Apache HTTP Server to recognize
the different hostnames. Name-based virtual hosting also eases
the demand for scarce IP addresses. Therefore you should use
name-based virtual hosting unless you are using equipment
that explicitly demands IP-based hosting. Historical reasons for
IP-based virtual hosting based on client support are no longer
applicable to a general-purpose web server.

Additional examples

Following are some specific examples of things you can do in
your HTML documents with SSI.

When was this document
modified?

Earlier, we mentioned that you could use SSI to inform the
user when the document was most recently modified. However, the
actual method for doing that was left somewhat in question. The
following code, placed in your HTML document, will put such a
time stamp on your page. Of course, you will have to have SSI
correctly enabled, as discussed above.

Of course, you will need to replace the
with the actual name of the file that
you’re referring to. This can be inconvenient if you’re just
looking for a generic piece of code that you can paste into any
file, so you probably want to use the
variable instead:

For more details on the format, go to
your favorite search site and look for . The
syntax is the same.

Including a standard footer

If you are managing any site that is more than a few pages,
you may find that making changes to all those pages can be a
real pain, particularly if you are trying to maintain some kind
of standard look across all those pages.

Using an include file for a header and/or a footer can
reduce the burden of these updates. You just have to make one
footer file, and then include it into each page with the
SSI command. The
function can determine what file to include with either the
attribute, or the
attribute. The attribute is a file path,
relative to the current directory. That means that it
cannot be an absolute file path (starting with /), nor can it
contain ../ as part of that path. The
attribute is probably more useful, and should specify a URL
relative to the document being served. It can start with a /,
but must be on the same server as the file being served.

Server Push

The HTTP/2 protocol allows the server to PUSH responses to a client it never
asked for. The tone of the conversation is: «here is a request that you
never sent and the response to it will arrive soon…»

But there are restrictions: the client can disable this feature and the
server may only ever PUSH on a request that came from the client.

The intention is to allow the server to send resources to the client that
it will most likely need: a css or javascript resource that belongs to a html
page the client requested. A set of images that is referenced by a css, etc.

The advantage for the client is that it saves the time to send the request which
may range from a few milliseconds to half a second, depending on where on the
globe both are located. The disadvantage is that the client may get sent
things it already has in its cache. Sure, HTTP/2 allows for the early cancellation
of such requests, but still there are resources wasted.

To summarize: there is no one good strategy on how to make best use of this
feature of HTTP/2 and everyone is still experimenting. So, how do you experiment
with it in Apache httpd?

inspect response header for headers
in a certain format:

Link </xxx.css>;rel=preload, </xxx.js>; rel=preload

If the connection supports PUSH, these two resources will be sent to the
client. As a web developer, you may set these headers either directly in
your application response or you configure the server via

<Location /xxx.html>
    Header add Link "</xxx.css>;rel=preload"
    Header add Link "</xxx.js>;rel=preload"
</Location>

If you want to use links without triggering a PUSH, you
can use the parameter, as in

Link </xxx.css>;rel=preload;nopush

or you may disable PUSHes for your server entirely with the directive

H2Push Off

And there is more:

The module will keep a diary of what has been PUSHed for each connection
(hashes of URLs, basically) and will not PUSH the same resource twice. When
the connection closes, this information is discarded.

There are people thinking about how a client can tell a server what it
already has, so PUSHes for those things can be avoided, but this is all
highly experimental right now.

Another experimental draft that has been implemented in
is the
Accept-Push-Policy Header Field where a client can, for each request, define
what kind of PUSHes it accepts.

PUSH might not always trigger the request/response/performance that one expects or
hopes for. There are various studies on this topic to be found on the web that explain
benefits and weaknesses and how different features of client and network influence
the outcome. For example: just because the server PUSHes a resource does not mean
a browser will actually use the data.

The major thing that influences the response being PUSHed is the request that was
simulated. The request URL for a PUSH is given by the application, but where do the
request headers come from? For example, will the PUSH request a
header and if yes with what value?

Apache will look at the original request (the one that triggered the PUSH) and copy the
following headers over to PUSH requests: , ,
, , .

Graceful Stop

Signal: WINCH

The or signal causes
the parent process to advise the children to exit after
their current request (or to exit immediately if they’re not
serving anything). The parent will then remove its and cease listening on
all ports. The parent will continue to run, and monitor children
which are handling requests. Once all children have finalised
and exited or the timeout specified by the has been
reached, the parent will also exit. If the timeout is reached,
any remaining children will be sent the signal
to force them to exit.

A signal will immediately terminate the
parent process and all children when in the «graceful» state. However
as the will
have been removed, you will not be able to use
or to send this signal.

Basic SSI directives

SSI directives have the following syntax:

It is formatted like an HTML comment, so if you don’t have
SSI correctly enabled, the browser will ignore it, but it will
still be visible in the HTML source. If you have SSI correctly
configured, the directive will be replaced with its
results.

The function can be one of a number of things, and we’ll talk
some more about most of these in the next installment of this
series. For now, here are some examples of what you can do with
SSI

Today’s date

The function just spits out the value of a
variable. There are a number of standard variables, which
include the whole set of environment variables that are
available to CGI programs. Also, you can define your own
variables with the function.

If you don’t like the format in which the date gets printed,
you can use the function, with a
attribute, to modify that formatting.

Including the results of a CGI program

This is one of the more common uses of SSI — to output the
results of a CGI program, such as everybody’s favorite, a «hit
counter.»

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:

Шаг 6 — Важные файлы и директории Apache

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

Контент

/var/www/html: фактический веб-контент, который по умолчанию состоит только из дефолтной страницы Apache, которую мы видели ранее, хранится в директории /var/www/html. Это может быть изменено в конфигурационных файлах Apache.

Конфигурация сервера

• : это конфигурационная директория Apache. Все файлы конфигурации Apache находятся здесь.
• : главный конфигурационный файл Apache. Изменения в этом файле влияют на глобальную конфигурацию Apache. Этот файл отвечает за загрузку многих других файлов из конфигурационной директории.
• : этот файл определяет порты, которые Apache будет слушать. По умолчанию Apache слушает порт 80, а также порт 443 при условии, что модуль для работы с SSL включен.
• : в этой директории хранятся файлы виртуальных хостов. Apache не использует файлы из этой директории, если ссылки на них нет в директории . Обычно настройка всех файлов виртуальных хостов осуществляется в этой директории, а активация хоста происходит путём создания ссылки в другой директории командой .
• : директория, в которой хранятся активированные виртуальные хосты. Обычно это делается путём создания ссылки на файл конфигурации хоста из директории с помощью команды . Apache читает конфигурационный файлы и ссылки из этой директории при запуске или перезапуске.
• , : эти директории связаны друг с другом так же, как и и связаны друг с другом, но используются для хранения фрагментов конфигурации, которые не принадлежат виртуальным хостам. Файлы в директории могут быть включены командой и выключены командой .
• , : эти директории содержат, соответственно, доступные и активные модули. Файлы, оканчивающиеся на , содержат фрагменты для загрузки конкретных модулей, а файлы, оканчивающиеся на , содержат настройки этих модулей. Модули можно активировать командой и деактивировать командой .

Серверные логи

• : по умолчанию каждый запрос к вашему веб-серверу записывается в этом файле, если только Apache не настроен на другое поведение.
• : по умолчанию все ошибки записываются в этот файл. Директива в конфигурации Apache определяет, насколько детальными должны быть записи об ошибках.

Преимущества и недостатки Apache

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

Плюсы

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

• Открытый исходный код. Он позволяет не только бесплатно скачивать программу, но и изменять ее под свои цели, чем и занимаются многие компании по всему миру, составляя уникальные конфигурации.
• Простота настройки. Помимо того, что в Apache есть огромное количество настроек, их редактирование остается таким же простым, а за вспомогательной информацией всегда можно обратиться к официальной документации.
• Модульная структура. Считаю, что возможность подключения любого количества модулей значительно расширяет функциональность веб-сервера, делая его универсальным.
• Кроссплатформенность. Скачать веб-сервер можно для любой операционной системы (но не для мобильной). При этом процесс настройки не меняется, различается только принцип инсталляции и расположение каталогов. Остается таким же и создание сайтов. Apache можно освоить как в Windows, так и в Linux или macOS.
• Масштабируемость. Данный веб-сервер подойдет как для одного сайта, так и для нескольких, расположенных на одном виртуальном хостинге.

Минусы

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

• Влияние трафика на производительность. Apache работает медленно, если наплыв пользователей слишком большой.
• Дыры в безопасности. Это относится только к тем случаям, когда к веб-серверу подключено огромное количество модулей. Чем их больше, тем сложнее процесс конфигурирования, появляются уязвимые места и дыры.
• Редактирование файлов в Linux. Управление конфигурационными файлами в этих дистрибутивах осуществляется вручную без графического интерфейса, что не всегда удобно (в качестве рекомендации могу подсказать приложение Apache GUI, благодаря которому настройку можно выполнить через веб-обозреватель).

Apache – несомненно, один из лучших веб-серверов, в чем вы смогли сами убедиться, дочитав мой обзор. 

Часто встречающиеся ошибки 1С и общие способы их решения Промо

Статья рассчитана в первую очередь на тех, кто недостаточно много работал с 1С и не успел набить шишек при встрече с часто встречающимися ошибками. Обычно можно определить для себя несколько действий благодаря которым можно определить решится ли проблема за несколько минут или же потребует дополнительного анализа. В первое время сталкиваясь с простыми ошибками тратил уйму времени на то, чтобы с ними разобраться. Конечно, интернет сильно помогает в таких вопросах, но не всегда есть возможность им воспользоваться. Поэтому надеюсь, что эта статья поможет кому-нибудь сэкономить время.

What they are/How to use them

files (or «distributed configuration files»)
provide a way to make configuration changes on a per-directory basis. A
file, containing one or more configuration directives, is placed in a
particular document directory, and the directives apply to that
directory, and all subdirectories thereof.

Note:

If you want to call your file something
else, you can change the name of the file using the directive. For example,
if you would rather call the file then you
can put the following in your server configuration file:

AccessFileName ".config"

In general, files use the same syntax as
the . What you can put in these files is determined by the
directive. This
directive specifies, in categories, what directives will be
honored if they are found in a file. If a
directive is permitted in a file, the
documentation for that directive will contain an Override section,
specifying what value must be in in order for that
directive to be permitted.

For example, if you look at the documentation for the
directive, you will find that it is permitted in
files. (See the Context line in the directive summary.) The line reads
. Thus, you must have at least
in order for this directive to be
honored in files.