Настройка nginx как front-end к apache на ubuntu 16.04

Введение

В этой статье я расскажу, как настроить производительный web сервер на базе популярного стека технологий — nginx и php-fpm. В связи с выходом нового релиза Centos 8, многие статьи на эту тему стали не актуальны, так как версии софта в базовых репозиториях обновились и тот же php нет смысла ставить из стороннего репозитория.

В самом конце я покажу, как настроить SELinux применительно к данному веб серверу. Приведу список правил, которые нужно будет применить конкретно к моей статье. Правила не универсальные. В зависимости от настройки web сервера, они будут отличаться. Если вам не хочется тратить на это свое время, или вам он не нужен, то просто отключите selinux. Если же нужен, то пока только добавляйте конфиги, но ничего не запускайте, пока не дойдете до самого конца. С включенным и не настроенным SELinux все равно ничего не заработает.

В своей тестовой среде я буду использовать следующие сущности.

z.serveradmin.ru	имя тестового виртуального хоста и сайта
/web/sites	директория для размещения виртуальных хостов
75.37.225.138	внешний ip адрес сервера
pma.serveradmin.ru	имя виртуального хоста для phpmyadmin

Подопытным сервером будет выступать виртуальная машина от ihor, характеристики следующие:

Процессор	4 ядра
Память	4 Gb
Диск	80 Gb SSD

Шаг 3. — Настройка файрвола UFW

Для тех кто файрвол не включил и не собирается включать — Переходите к

Напомню! файрвол UFW мы включили в этой статье — Первоначальная настройка Ubuntu Server 18.04

Посмотрим профили приложений в файрволе UFW.(Рис.5)

sudo ufw app list

Рис.5 — Просматриваем профили приложений UFW.

Видим три профиля Nginx:

Nginx Full — открывает два порта 80 — http [ нешифрованный веб-трафик и 443 — https [ TLS / SSL — зашифрованный веб-трафик
Nginx HTTP — открывает стандартный 80 порт — http нешифрованный веб-трафик
Nginx HTTPS — открывает только 443 порт — https [ TLS / SSL — зашифрованный веб-трафик

Для того чтобы применить какой-либо профиль можно воспользоваться командой — sudo ufw allow ‘Имя_профиля’

Мы применим первый профиль — Nginx HTTP.(Рис.6)

sudo ufw allow 'Nginx HTTP'

Рис.6 — Применяем профиль Nginx в файволе UFW.

Правило применилось!

Выпуск самоподписанного сертификата (необязательно)

После установки Nginx в операционной системе уже должен быть установлен openssl. Поэтому можно сразу приступить к генерации сертификата.

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

cd /etc/ssl/certs

После чего требуется ввести команду генерации сертификата, где вместо <SERVER> нужно подставить имя компьютера, на котором планируется размещен Apache:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout <SERVER>.key -out <SERVER>.crt

Во время выполнения команды будет задано несколько вопросов. Для «Common Name (e.g. server FQDN or Your bane)» нужно также указать имя сервера. Остальные поля заполняются произвольно (кроме «Country name» — здесь можно оставить по умолчанию).

Глобальные настройки Apache

Данный раздел рассматривает важные параметры глобальных настроек Apache.

Timeout

По умолчанию этот параметр имеет значение 300. Это значит, что на выполнение каждого запроса у сервера есть максимум 300 секунд. В большинстве случаев это значение очень большое, и его рекомендуют уменьшить до 30-60 секунд.

KeepAlive

Если этот параметр имеет значение On, сервер позволит клиенту запрашивать несколько объектов в рамках одного соединения. Если параметр имеет значение Off, то каждый новый запрос будет создавать индивидуальное соединение. Такое поведение может привести к перенагрузке сайта с большим трафиком.

MaxKeepAliveRequests

Этот параметр позволяет определить максимальное количество запросов для одного соединения. Это позволяет увеличить производительность Apache.

Значение 0 позволит веб-серверу обрабатывать неограниченное количество запросов в рамках одного соединения.

KeepAliveTimeout

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

Защита данных

Стек защиты данных в ASP.NET Core используется определенным ПО промежуточного слоя ASP.NET Core, включая промежуточное ПО для проверки подлинности (например, промежуточное ПО файлов cookie) и средствами защиты от подделки межсайтовых запросов. Даже если API-интерфейсы защиты данных не вызываются из пользовательского кода, необходимо настроить защиту данных для создания постоянного хранилища криптографических ключей. Если защита данных не настроена, ключи хранятся в памяти и удаляются при перезапуске приложения.

Если набор ключей хранится в памяти, при перезапуске приложения происходит следующее:

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

Сведения о настройке защиты данных для хранения и шифрования набора ключей см. в приведенных ниже статьях.

Поставщики хранилища ключей в ASP.NET Core
Шифрование неактивных ключей в Windows и Azure с помощью ASP.NET Core

Установка php-fpm

Установка php-fpm в Centos 8 сильно упростилась по сравнению с предыдущей версией, потому что в базовом репозитории хранится актуальная версия php 7.2, которой можно пользоваться. Пока нет необходимости подключать сторонние репозитории, так как версия 7.2 вполне свежа и актуальна. Если у вас нет необходимости использовать что-то новее, то можно остановиться на этой версии.

Устанавливаем php и php-fpm в CentOS 8, а так же некоторые популярные модули.

Проверим конфигурацию php-fpm, которая располагается в файле /etc/php-fpm.d/www.conf. Изменим пользователя, под которым будет работать php-fpm с apache на nginx.

Перезапускаем php-fpm и проверяем, запущен ли сокет.

Все в порядке, php-fpm запущен и готов к работе. Cделаем еще одну важную настройку. Назначим nginx владельцем директории для хранения сессий php.

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

Возможно, вам захочется поставить более свежу версию php. Как это сделать, читайте в отдельной статье — обновление php-7.2 до 7.4 в CentOS 8.

Для того, чтобы проверить работу нашего веб сервера, нужно установить ssl сертификаты. Без них nginx с текущим конфигом не запустится. Исправляем это.

Установка

Разобьем установку на части. Установим базу данных PostgreSQL, интерпретатор PHP, далее web-сервер Nginx, ну и последним пунктом наше облако NextCloud:

Установка PHP

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

После этого устанавливаем PHP и необходимые зависимости для NextCloud.

Установка Web-сервера Nginx

Для установки nginx для начала добавим, как и с PHP, более новый репозиторий:

Теперь можно установить наш web-сервер. Устанавливать будем сборку в которую включен модуль для проигрывания потокового видео с нашего сервера (поддержка модуля mp4). Открываем терминал и набираем:

Установка NextCloud

После всех пунктов выше приступим к установки нашего домашнего облака NextCloud. Для этого переходим в директорию :

Скачиваем последнюю версию NextCloud (на момент написания статьи версия NextCloud была 21.0.0), а также сразу распакуем и изменим права на директорию NextCloud:

Основные ошибки nginx и их устранение

502 Bad Gateway

Ошибка означает, что NGINX не может получить ответ от одного из сервисов на сервере. Довольно часто эта ошибка появляется, когда NGINX работает в связке с Apache, Varnish, Memcached или иным сервисом, а также обрабатывает запросы PHP-FPM.
Как правило, проблема возникает из-за отключенного сервиса (в этом случае нужно проверить состояние напарника и при необходимости перезапустить его) либо, если они находятся на разных серверах, проверить пинг между ними, так как, возможно, отсутствует связь между ними.
Также, для PHP-FPM нужно проверить права доступа к сокету.
Для этого убедитесь, что в прописаны правильные права

listen = /tmp/php5-fpm.sock 
listen.group = www-data
listen.owner = www-data

504 Gateway Time-out

Ошибка означает, что nginx долгое время не может получить ответ от какого-то сервиса. Такое происходит, если Apache, с которым NGINX работает в связке, отдаёт ответ слишком медленно.
Проблему можно устранить с помощью увеличения времени таймаута.
При работе в связке NGINX+Apache в конфигурационный файл можно внести изменения:

server { 
... 
   send_timeout 800;
   proxy_send_timeout 800;
   proxy_connect_timeout 800;  
   proxy_read_timeout 800;  
... 
}

Тут мы выставили ожидание таймаута в 800 секунд.

Upstream timed out (110: Connection timed out) while reading response header from upstream

Причиной может быть сложная и потому долгая обработка php в работе PHP-FPM.
Здесь тоже можно увеличить время ожидания таймаута

location ~ \.php$ { 
   include fastcgi_params;
   fastcgi_index index.php; 
   fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; 
   fastcgi_pass unix:/tmp/php5-fpm.sock;  
   fastcgi_read_timeout 800;
}

800 секунд на ожидание ответа от бекенда.

Это лишь временные меры, так как при увеличении нагрузки на сайт ошибка снова станет появляться. Устраните узкие места, оптимизируйте работу скриптов php

413 Request Entity Too Large

Ошибка означает, что вы пытались загрузить слишком большой файл. В настройках nginx по умолчанию стоит ограничение в 1Mb.
Для устранения ошибки в nginx.conf нужно найти строку

client_max_body_size 1m;

и заменить значение на нужное. Например, мы увеличим размер загружаемых файлов до

client_max_body_size 100m;

Также, можно отключить проверку размера тела ответа полностью значением ноль:

client_max_body_size 0;

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

После каждого внесённого изменения в конфигурационный файл необходимо перезагружать nginx

304 Not Modified не устанавливается

Если возникает проблема с правильным отображением ответного заголовка сервера , то проблема, скорее всего, в пунктах:

В секции конкретного сайта включен (Подробнее в документации). По умолчанию, ssi отключен, но некоторые хостеры и ISPManager любят его прописывать в дефолтную конфигурацию сайта включенным. Его нужно обязательно отключить, закомментировав или удалив эту строку;
if_modified_since установить в , то есть на уровне или конкретного прописать:

Правильность ответа можно проверить с помощью:

Консоли разработчика браузера (F12) в разделе (не забываем перезагружать страницу);
Или сторонних сервисов, например last-modified.com.

Решение проблем

Валидация конфигурации

# nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

При доступе с локального IP перенаправляется на localhost

В файле найдите незакомментированную строку (без вначале) и добавьте под ней:

server_name_in_redirect off;

По умолчанию, nginx перенаправляет любые запросы на указанное в опции имя.

Это из-за того, что сервер FastCGI не запущен или используемый сокет имеет неправильные права доступа.

При определённых обстоятельствах, может не запуститься правильно и создать бесполезный сокет юникс домена .

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

Затем запустите вместо него.
Проверьте статус и нового доменного юникс сокета :

$ systemctl status fcgiwrap.service
$ ls /run/fcgiwrap.sock

Если это сработало, отключите и включите .

Ошибка: No input file specified

1. Скорее всего у вас не установлена переменная , содержащая полный путь до ваших скриптов. Если конфигурация nginx () правильная, то эта ошибка означает, что php не смог загрузить запрашиваемый скрипт. Часто это просто оказывается ошибкой прав доступа, и вы можете запустить php-cgi с правами root:

# spawn-fcgi -a 127.0.0.1 -p 9000 -f /usr/bin/php-cgi

или вам следует создать группу и пользователя для запуска php-cgi:

# groupadd www
# useradd -g www www
# chmod +w /srv/www/nginx/html
# chown -R www:www /srv/www/nginx/html
# spawn-fcgi -a 127.0.0.1 -p 9000 -u www -g www -f /usr/bin/php-cgi

2. Другой причиной может быть то, что задан неправильный аргумент в секции в . Убедитесь, что указывает на ту же директорию, что и в на том же сервере. Либо вы можете просто задать абсолютный путь до корневого каталога, не определяя его в каких-либо location секциях.

3. Убедитесь, что переменная в также содержит путь, который соответствует аргументу в .

Также обратите внимание, что не только php-скрипты должны иметь права на чтение, но также и вся структура каталогов должна иметь право на исполнение, чтобы пользователь PHP мог добраться до этого каталога.

Ошибка: «File not found» в браузере или «Primary script unknown» в лог-файле

Убедитесь, что вы определили и в ваших директивах или :

 location ~ \.php$ {
      root           /srv/http/root_dir;
      index          index.php;
      fastcgi_pass   unix:/run/php-fpm/php-fpm.sock;
      include        fastcgi.conf;
 }

Также убедитесь, что запрашиваемый файл существует на сервере.

Ошибка: chroot: ‘/usr/sbin/nginx’ No such file or directory

Если у вас возникает эта ошибка при запуске демона nginx в chroot, скорее всего, это происходит из-за отсутствующих 64-битных библиотек в изолированном окружении.

Если ваш chroot запущен в , вам нужно добавить требуемые 64-битные библиотеки.

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

# mkdir /srv/http/usr/lib64
# cd /srv/http; ln -s usr/lib64 lib64

Затем скопируйте требуемые 64-битные библиотеки, перечисленные командой в .

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

Альтернативный скрипт для systemd

/etc/nginx/nginx.conf

user http;
pid /run/nginx.pid;

абсолютным путем к файлу является .3

/etc/systemd/system/nginx.service

Description=nginx (Chroot)
After=syslog.target network.target


Type=forking
PIDFile=/srv/http/run/nginx.pid
RootDirectory=/srv/http
ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf
ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf
ExecReload=/usr/sbin/nginx -c /etc/nginx/nginx.conf -s reload
ExecStop=/usr/sbin/nginx -c /etc/nginx/nginx.conf -s stop


WantedBy=multi-user.target

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

/etc/systemd/system/nginx.path

Description=nginx (Chroot) path

PathExists=/srv/http/site/Public_html

WantedBy=default.target

Включите и замените на in .

Ссылка в файле юнита позволяет systemd следить за процессом (необходим абсолютный путь). Если это нежелательно, вы можете изменить тип one-shoot по умолчанию и удалить ссылку из файла юнита.

Шаг 1. — Подготовка

На этапе подготовки мы убеждаемся что у нас есть всё необходимое для выполнения дальнейшей инструкции:

Нам нужна установленная ОС Ubuntu Server 18.04 — Вам в помощь статья — Установка Ubuntu Server 18.04 LTS
Ubuntu Server 18.04 должна иметь статический IP-адрес и доступ в интернет — Настройка сети в Ubuntu Server 18.04
Необязательно, но желательно включить фаервол UFW — Первоначальная настройка Ubuntu Server 18.04

Посмотрим свой IP-адрес, командой ifconfig.(Рис.1)

ifconfig

Рис.1 — Командой ifconfig узнаём IP-адрес нашего сервера.

Адрес моего сервера — 192.168.3.9, в этой статье я буду вводить его в браузере на другом ПК, для проверки работоспособности Nginx. Вы должны будете ввести свой IP-адрес.

Если у вас, допустим, Ubuntu Desktop 18.04 и нету возможности подключиться с другого ПК, то вводите на своей же Ubuntu в браузере -«localhost» или IP-адрес — 127.0.0.1

Всё! На этом подготовка завершена.

Структура файла конфигурации Nginx и рекомендации

Все файлы конфигурации Nginx находятся в каталоге .
Главный файл конфигурации Nginx — это .
Чтобы упростить поддержку конфигурации Nginx, рекомендуется создать отдельный файл конфигурации для каждого домена. У вас может быть столько файлов блоков сервера, сколько вам нужно.
Файлы блоков сервера Nginx хранятся в каталоге . Файлы конфигурации, найденные в этом каталоге, не используются Nginx, если они не связаны с каталогом .
Чтобы активировать серверный блок, вам необходимо создать символическую ссылку (указатель) из файла конфигурации sites в каталоге с каталог с поддержкой .
Рекомендуется следовать стандартному соглашению об именах, например, если ваше доменное имя — тогда ваш файл конфигурации должен называться
Каталог содержит фрагменты конфигурации, которые можно включить в файлы блоков сервера. Если вы используете повторяющиеся сегменты конфигурации, вы можете преобразовать эти сегменты в фрагменты и включить файл фрагмента в блоки сервера.
Файлы журнала Nginx ( и ) находятся в каталоге . Рекомендуется иметь разные файлы и журналов для каждого блока сервера.
Вы можете установить корневой каталог документов домена в любое место. Наиболее распространенные места для webroot:

Шаг 2 — Настройка правил брандмауэра

Если вы активировали брандмауэр согласно требованиям нашего руководства по первоначальной настройке для CentOS 8, вам потребуется изменить настройки брандмауэра, чтобы разрешить внешние подключения к вашему веб-серверу Nginx, который запускается на порту по умолчанию.

Запустите следующую команду, чтобы на постоянной основе активировать соединения HTTP для порта :

Чтобы подтвердить, что служба брандмауэра добавлена надлежащим образом, вы можете запустить следующую команду:

Вывод будет выглядеть следующим образом:

Для применения изменений вам необходимо перезагрузить службу брандмауэра:

Теперь сервер Nginx полностью установлен и доступен для внешних посетителей.

Мониторинг приложения

Сервер настроен на переадресацию запросов к в приложение ASP.NET Core, работающее на базе Kestrel по адресу . При этом в Nginx не настроено управление процессом Kestrel. Для запуска и мониторинга соответствующего веб-приложения можно использовать и создать файл службы. — это система инициализации, предоставляющая различные функции для запуска и остановки процессов, а также управления ими.

Создание файла службы

Создайте файл определения службы.

Далее представлен пример файла службы для нашего приложения:

В предыдущем примере управляющий службой пользователь задается с помощью параметра . Этот пользователь () должен существовать и иметь права владельца в отношении файлов приложения.

Используйте , чтобы настроить время ожидания до завершения работы приложения после начального сигнала прерывания. Если приложение не завершит работу в течение этого периода, оно прерывается сигналом SIGKILL. Укажите значение в секундах без единиц измерения (например, ), значение интервала (например, ) или значение , которое отключает время ожидания. по умолчанию использует значение в файле конфигурации диспетчера (, , , ). В большинстве дистрибутивов по умолчанию устанавливается время ожидания 90 секунд.

Linux имеет файловую систему, в которой учитывается регистр символов. Задание для приведет к поиску файла конфигурации , а не .

Некоторые значения (например, строки подключения SQL) необходимо экранировать, чтобы поставщики конфигурации могли читать переменные среды. Используйте следующую команду, чтобы создать правильно экранированное значение для файла конфигурации:

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

Сохраните файл и включите службу.

Запустите службу и убедитесь, что она работает.

Теперь, когда обратный прокси-сервер настроен и Kestrel управляется через , веб-приложение можно считать полностью настроенным и оно доступно через в браузере на локальном компьютере. Оно также доступно для удаленных компьютеров, несмотря на наличие блокирующих трафик межсетевых экранов. Заголовок ответа подтверждает, что приложение ASP.NET Core обслуживается Kestrel.

Просмотр журналов

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

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

Конфигурации виртуальных хостов

Стандартный виртуальный хост находится в файле default в каталоге sites-available.

Чтобы ознакомиться с общим форматом виртуального хоста, откройте этот файл:

По умолчанию виртуальный хост обрабатывает запросы на порте 80.

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

Настройки виртуального хоста высшего уровня

Эти параметры устанавливаются в разделе Virtual Host и применяются ко всему виртуальному хосту.

Директива ServerName задаёт доменное имя или IP-адрес сервера. Это индивидуальный параметр каждого виртуального хоста, который может переопределить настройки по умолчанию, если он совпадает со значением ServerName.

Параметр ServerAlias позволяет добавить алиасы сайта – альтернативные имена и пути, ведущие к одному контенту. Так, например, часто устанавливается алиас домена с www.

DocumentRoot задаёт каталог, в котором веб-сервер хранит контент данного виртуального хоста. В Ubuntu для этого по умолчанию используется /var/www.

В конфигурации виртуального хоста есть специальный раздел для настройки обработки отдельных каталогов файловой системы. Эти настройки также можно переопределять.

Сначала виртуальный хост предлагает набор правил для каталога / (root-каталог). Этот раздел обеспечит базовую конфигурацию виртуального хоста, поскольку он относится ко всем файлам, которые обслуживаются в файловой системе.

По умолчанию Ubuntu не накладывает никаких ограничений на файловую систему. Apache рекомендует добавить несколько стандартных ограничений доступа, например:

Это заблокирует доступ ко всему контенту, если в последующих определениях каталогов не указано иное.

Далее идут настройки каталога document root, в которых параметр allow from all переопределяет параметры каталога /.

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

Настройки Alias и ScriptAlias

Иногда перед разделом Directory идут параметры Alias и ScriptAlias.

Директива Alias позволяет добавлять к обслуживаемому контенту каталоги вне DocumentRoot.

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

К примеру, такая строка в виртуальном хосте для сайта example.com откроет доступ к контенту в каталоге /path/to/content/ при запросе example.com/content/.

Помните, что открывая доступ к дополнительным каталогам, нужно устанавливать ограниченные привилегии на них.

Включение сайтов и модулей в Apache

Создав файл виртуального хоста, вы можете включить его. Для этого нужно создать символическую ссылку на файл в каталоге sites-enabled:

Включив сайт, перезапустите Apache, чтобы веб-сервер перечитал конфигурации:

Чтобы отключить виртуальный хост, нужно удалить символьную ссылку из sites-enabled:

После этого нужно снова перезапустить веб-сервер:

Включить и отключить модуль Apache можно с помощью следующих команд (соответственно):

Они работают так же, как и ранее упомянутые команды a2ensite иa2dissite. После включения или отключения модуля нужно перезапускать веб-сервер.

Установка Nginx под Linux

Итак, предполагается, что есть только что установленная операционная система Ubuntu 18.04 LTS без графического интерфейса пользователя.

Перед тем как продолжить, нужно проверить доступные версии программного обеспечения дистрибутива. Выполняем команду:

sudo apt update

В выводе результата команды можно увидеть, что доступны обновления. Рекомендуются их обновить с помощью команды (подсказка «Run ‘apt list –upgradable’»):

sudo apt upgrade

По завершению обновления пакетов приложений можно приступить к установке непосредственно веб-сервера.

Нужно выполнить команду команду:

sudo apt install nginx

Необходимо дождаться окончание выполнения команды и убедиться, что в момент установки никаких ошибок не возникло. В данном случае установка прошла без проблем.

Далее нужно проверить, что помимо самой установки, веб-сервер запустился и готов обрабатывать запросы (для данной команды использование sudo не обязательно):

service nginx status

В ответ можно увидеть, что состояние службы active (running). Это значит, что веб-сервер работает в штатном режиме, и можно переходить к настройке трансляции запросов либо к генерации самоподписанного сертификата (если в этом есть необходимость).

Шаг 3 — Управление процессом Apache

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

Чтобы остановить веб-сервер, введите:

Чтобы запустить остановленный веб-сервер, введите:

Чтобы остановить и снова запустить службу, введите:

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

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

Чтобы перезагрузить службу для запуска во время загрузки, введите:

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

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

Установка GoAccess в Unix/Linux

Приведу примеры установок для различных Unix и Linux ОС.

Устанавливаем на deb’s ОС:

# aptitude install goaccess

ИЛИ

$ echo "deb http://deb.goaccess.io/ $(lsb_release -cs) main" | sudo tee -a /etc/apt/sources.list.d/goaccess.list
$ wget -O - http://deb.goaccess.io/gnugpg.key | sudo apt-key add -
$ sudo apt-get update
$ sudo apt-get install goaccess

Устанавливаем на rpm’s ОС:

# yum install goaccess

Устанавливаем на Arch Linux:

# pacman -S goaccess

Устанавливаем на Gentoo:

# emerge net-analyzer/goaccess

Устанавливаем на OS X / Homebrew:

# brew install goaccess

Устанавливаем на FreeBSD:

# cd /usr/ports/sysutils/goaccess/ && make install clean
# pkg install sysutils/goaccess

Компилируем с исходного кода:

Во-первых нужно скачать последнюю стабильную версию GoAccess.

# cd /usr/local/src/
# wget http://tar.goaccess.io/goaccess-1.0.2.tar.gz
# tar -xzvf goaccess-*

После чего переходим в распакованный каталог и выполняем сборку программы, если вы хотите можно разрешить сборку с geoip (но лучше прочитать README или INSTALL):

# ./configure --enable-geoip
# make && make install && make clean

Так же, можно использовать git:

$ cd /usr/local/src/ && git clone https://github.com/allinurl/goaccess.git && cd goaccess
$ autoreconf -fiv
$ ./configure --enable-geoip --enable-utf8
$ make && sudo make install

PS: Установите git если не установлен!

С установкой я закончил, перехожу к использованию данной утилиты.

Установка phpmyadmin

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

Идем на сайт https://www.phpmyadmin.net и копируем ссылку на последнюю версию панели. Затем загружаем ее через консоль.

Архив упакован в zip. Если у вас нет на сервере пакета unzip, установите его.

Распаковываем исходники в директорию виртуального хоста.

Можно заходить и проверять работу phpmyadmin, пройдя по адресу pma.serveradmin.ru. Ее установка закончена.

Более подробно вопрос установки и настройки phpmyadmin я рассматривал отдельно. Можете зайти в панель и создать базу mysql для тестового сайта, например, wordpress. Затем через консоль загрузить исходники cms и распаковать их.

После этого открывайте в браузере страницу z.serveradmin.ru и увидите приветсвие установщика wordpress.

На этом основная настройка web сервера завершена. Он уже полностью работоспособен. Если вам достаочно этого функционала, то можете сразу переходить к настройке ротации логов.