Установка и настройка сервера apache 2.4

Шаг 1. Создание сертификата

Для боевого сервера, сертификат должен быть получен от доверенного центра сертификации — либо локального для компании, либо коммерческого. Или получен бесплатно от Let’s Ecnrypt.

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

а) на Red Hat / CentOS:

cd /etc/httpd

б) на Debian / Ubuntu:

cd /etc/apache2

в) во FreeBSD:

cd /usr/local/etc/apache24

Создаем папку для сертификатов и переходим в нее:

mkdir ssl ; cd ssl

И генерируем сертификат:

openssl req -new -x509 -days 1461 -nodes -out cert.pem -keyout cert.key -subj «/C=RU/ST=SPb/L=SPb/O=Global Security/OU=IT Department/CN=test.dmosk.local/CN=test»

* в данном примере созданы открытый и закрытый ключи на 4 года (1461 день); значения параметра subj могут быть любыми в рамках тестирования.

Работа веб-сервера Apache

Веб-сервер Apache – это программное обеспечение, которое установлено на сам сервер. Как мы уже поняли, благодаря ему устанавливается соединение между юзером, использующим браузер, и сервером, чтобы осуществить передачу данных при запросе. Пользователь переходит на страницу, далее отправляется сигнал на обработку, Apache находит необходимые данные и возвращает их пользователю, чтобы тот смог ознакомиться с ними. Работает это и в обратном направлении, примерно по такому же принципу.

Все остальное зависит от подключаемых модулей, которые существуют для Apache Web Server, то есть его можно назвать модульным (собираемым из разных дополнений, расширяющих функциональность). Здесь уже создатель сайта сам решает, какие дополнения установить, редактируя конфигурацию через специальный файл под названием .htaccess. Дополнений существует множество – начиная со средств повышения безопасности и заканчивая модулями аутентификации пользователей при вводе учетных данных.

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.

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

Инструкции:

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
53. Как собрать собственный установочный RPM-пакет с Prometheus Server

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:

Variables ¶

The expression parser provides a number of variables of the form
. Note that the value of a variable may depend
on the phase of the request processing in which it is evaluated. For
example, an expression used in an
directive is evaluated before authentication is done. Therefore,
will not be set in this case.

The following variables provide the values of the named HTTP request
headers. The values of other headers can be obtained with the
. Using these
variables may cause the header name to be added to the Vary
header of the HTTP response, except where otherwise noted for the
directive accepting the expression. The
may be used to circumvent this
behavior.

Name

Other request related variables

Name	Description
	The HTTP method of the incoming request (e.g. )
	The scheme part of the request’s URI
	The path part of the request’s URI
	Same as
	The full local filesystem path to the file or script matching the request, if this has already been determined by the server at the time is referenced. Otherwise, such as when used in virtual host context, the same value as
	Same as
	The date and time of last modification of the file in the format , if this has already been determined by the server at the time is referenced.
	The user name of the owner of the script.
	The group name of the group of the script.
	The trailing path name information, see
	The query string of the current request
	«» if the current request is a subrequest, «» otherwise
	The complete request line (e.g., «»)
	The IP address of the remote host
	The port of the remote host (2.4.26 and later)
	The host name of the remote host
	The name of the authenticated user, if any (not available during )
	The user name set by
	The of the current vhost
	The server port of the current vhost, see
	The of the current vhost
	The protocol used by the request (e.g. HTTP/1.1). In some types of internal subrequests, this variable has the value .
	A number that encodes the HTTP version of the request: . For example, corresponds to HTTP/1.1 and corresponds to HTTP/0.9
	The major version part of the HTTP version of the request, e.g. for HTTP/1.0
	The minor version part of the HTTP version of the request, e.g. for HTTP/1.0
	The of the current vhost
	The configured (e.g. «»)
	The content type of the response (not available during )
	The name of the handler creating the response
	«» if the request uses http/2, «» otherwise
	«» if the request uses https, «» otherwise
	«» if the connection uses IPv6, «» otherwise
	The HTTP error status of the request (not available during )
	The error log id of the request (see )
	The error log id of the connection (see )
	The peer IP address of the connection (see the module)

Misc variables

Name	Description
	The current year (e.g. )
	The current month (, …, )
	The current day of the month (, …)
	The hour part of the current time (, …, )
	The minute part of the current time
	The second part of the current time
	The day of the week (starting with for Sunday)
	The date and time in the format
	The server version string
	The date of the API version (module magic number)

Some modules register additional variables, see e.g.
.

Any variable can be embedded in a string, both in quoted
strings from boolean expressions but also in string expressions,
resulting in the concatenation of the constant and dynamic parts as
expected.

Upgrading

The first step in upgrading is to read the release announcement
and the file in the source distribution to
find any changes that may affect your site. When changing between
major releases (for example, from 2.0 to 2.2 or from 2.2 to 2.4),
there will likely be major differences in the compile-time and
run-time configuration that will require manual adjustments. All
modules will also need to be upgraded to accommodate changes in the
module API.

Upgrading from one minor version to the next (for example, from
2.2.55 to 2.2.57) is easier. The
process will not overwrite any of your existing documents, log
files, or configuration files. In addition, the developers make
every effort to avoid incompatible changes in the
options, run-time configuration, or the
module API between minor versions. In most cases you should be able to
use an identical command line, an identical
configuration file, and all of your modules should continue to
work.

To upgrade across minor versions, start by finding the file
in the directory of
your installed server or at the root of the source tree for your
old install. This will contain the exact
command line that you used to
configure the source tree. Then to upgrade from one version to
the next, you need only copy the file to
the source tree of the new version, edit it to make any desired
changes, and then run:

You should always test any new version in your
environment before putting it into production. For example, you
can install and run the new version along side the old one by
using a different and a
different port (by adjusting the directive) to test for any
incompatibilities before doing the final upgrade.

You can pass additional arguments to ,
which will be appended to your original
options:

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

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.

Log Files and Troubleshooting ¶

As an Apache HTTP Server administrator, your most valuable assets are
the log files, and, in particular, the error log. Troubleshooting any
problem without the error log is like driving with your eyes closed.

The location of the error log is defined by the directive, which may be set globally,
or per virtual host. Entries in the error log tell you what went wrong,
and when. They often also tell you how to fix it. Each error log message
contains an error code, which you can search for online for even more
detailed descriptions of how to address the problem. You can also
configure your error log to contain a log ID which you can then
correlate to an access log entry, so that you can determine what request
caused the error condition.

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:

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.

Настройка виртуальных хостов Apache2 в Ubuntu

Виртуальные хосты позволяют размещать более одного веб-сайта на одном сервере Apache2. В Nginx это называется серверными блоками.

По умолчанию Apache2 поставляется с одним виртуальным хостом, а его конфигурационная информация хранится в файле /etc/apache2/sites-enabled/000-default.conf. Кроме того, корень веб-сайта по умолчанию — располагается в  /var/www/html.

Настроить новый виртуальный хост очень просто. Следуйте инструкции и просто замените setiwik своим собственным зарегистрированным доменным именем.

Создание виртуального хоста

Создайте новый конфигурационный файл виртуального хоста, скопировав файл по умолчанию следующим образом.

Далее отключите виртуальный хост по умолчанию с помощью приведенной ниже команды.

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

Затем сделайте учетную запись Пользователя службы Apache2 (www-data) и группу (www-data) владельцами корневого каталога документа. Это можно сделать следующим образом.

Далее, предоставьте учетной записи Пользователя службы Apache2 (www-data) полный доступ к корневому каталогу документа с помощью следующей команды.

Создание индексного файла сайта

Теперь создайте индексный файл в корневом каталоге документа с помощью команды:

Скопируйте и вставьте пример HTML-кода ниже.

Сохраните и закройте файл index.html.

Измените конфигурацию виртуального хоста

Затем отредактируйте новый файл конфигурации виртуального хоста с помощью следующей команды.

Теперь раскомментируйте строку, которая начинается с ServerName, а затем замените www.example.com с фактическим URL-адресом веб-сайта. А так же замените /var/www/html новым корневым путем документа.

Ниже приведен пример того, что ожидается после внесения изменений.

Сохраните и закройте файл конфигурации виртуального хоста.

Включите виртуальный хост Apache2

Чтобы включить виртуальный хост Apache2, выполните команду.

Наконец, перезапустите веб-сервер Apache2 с помощью:

Теперь мой сайт доступен через www.setiwik.ru как показано на рисунке ниже.

Добро пожаловать в виртуальный хост setiwik

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

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

Authentication example

If you jumped directly to this part of the document to find out how
to do authentication, it is important to note one thing. There is a
common misconception that you are required to use
files in order to implement password
authentication. This is not the case. Putting authentication directives
in a
section, in your main server configuration file, is the preferred way
to implement this, and files should be used only
if you don’t have access to the main server configuration file. See for a discussion of when you should and should
not use files.

Having said that, if you still think you need to use a
file, you may find that a configuration such as
what follows may work for you.

file contents:

AuthType Basic
AuthName "Password Required"
AuthUserFile "/www/passwords/password.file"
AuthGroupFile "/www/passwords/group.file"
Require group admins

Note that must be in effect
for these directives to have any effect.

Настройка

 sudo service apache2 restart

• Свои настройки следует сохранять в директорию или
• Для активации файла настройки следует выполнить команду:

 sudo a2enconf <config-file-name>

Виртуальные хосты

• Файлы настроек виртуальных хостов хранятся в . По умолчанию в Apache уже настроен один виртуальный хост. Его настройки лежат в файле (в новых версиях файл может называться ). Вы можете использовать этот виртуальный хост в качестве примера.
• Пример настройки виртуального хоста:

 <VirtualHost *:80>
 #Имя хоста
 ServerName host1.server1
 #Корневая папка хоста
 DocumentRoot /var/www/host1.server1
 <Directory /var/www/host1.server1>
 #Разрешение на перезапись всех директив при помощи .htaccess
 AllowOverride All
 </Directory>
 </VirtualHost>

• Назовите файл настройки именем вашего хоста и сохраните.
• После создания файла настроек допишите в имя вашего хоста:

 127.0.0.1    host1.server1

Для включения созданного виртуального хоста используется утилита a2ensite:

 sudo a2ensite host1.server1

Отключается хост аналогично утилитой a2dissite:

 sudo a2dissite host1.server1

Здесь host1.server1 — имя файла настроек вашего хоста в /etc/apache2/sites-available

Модули

Настройки модулей хранятся в директории /etc/apache2/mods-available. Для включения или отключения модулей используются a2enmod и a2dismod соответственно.

mod_userdir

• Модуль позволяет использовать директории, находящиеся в домашних директориях пользователей для хранения веб страниц. По умолчанию Apache ищет запрашиваемые страницы в директории

  mkdir ~/public_html

• Чтобы включить mod_userdir, выполните:

и добавьте необходимого пользователя в группу www-data:

после чего перезагрузите Apache:

Страницы будут доступны по адресу http://localhost/~username, где username — имя пользователя.

CGI

Если Вы хотите запускать на сервере cgi-скрипты, подключите модуль cgi командой

 sudo a2enmod cgi

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

PHP5

Для включения поддержки PHP5 в качестве модуля Apache необходимо установить пакет libapache2-mod-php5:

 sudo apt-get install libapache2-mod-php5

Если же вы хотите установить PHP5 как отдельную CGI-программу, то установите пакет php5-cgi

 sudo apt-get install php5-cgi

1С:Предприятие Бухгалтерия переход с редакции 2.0 на 3.0. Практика перевода информационной базы для работы в управляемом приложении. Промо

Из информационного выпуска 1С № 16872 от 08.07.2013г. стало известно об относительно скором необходимом переходе на редакцию 1С:Бухгалтерия 3.0. В данной публикации будут разобраны некоторые особенности перевода нетиповой конфигурации 1С:Бухгалтерия 2.0 на редакцию 3.0, которая работает в режиме «Управляемое приложение».
Публикация будет дополняться по мере подготовки нового материала. Публикация не является «универсальной инструкцией».

Update 3. Права доступа. 14.08.2013
Update 4. Добавлен раздел 0. Дополнен раздел 4. Добавлен раздел 7. Внесены поправки, актуализирована информация. 23.11.2013.

1 стартмани

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.

Пример использования файла .htaccess

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

Самая простая строка кода, вводимая в этот файл выглядит так:

AddType "text/html; charset=utf-8" .html .htm .shtml

Ее основное предназначение – указать Apache кодировку, в которой нужно возвращать текст пользователю. Такое изменение делается в тех случаях, когда стандартный вывод вас не устраивает.

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

Если вы нуждаетесь в получении дополнительной информации о виртуальном хостинге с этим веб-сервером, ознакомьтесь с документацией Virtual Apache Host на официальном сайте разработчика ПО.

Подробнее: Apache Virtual Host documentation

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.

Шаг 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 определяет, насколько детальными должны быть записи об ошибках.