Сегодня разберем как можно изменить шаблоны VestaCP у Web сервера Nginx для получения рейтинга A+.

Лучше всего отредактировать /usr/local/vesta/data/templates/web/nginx/default.stpl тем более, что VestaCP перезапишет сделанные вручную в конфигурационном файле изменения.

sudo nano /usr/local/vesta/data/templates/web/nginx/default.stpl

Поддержка SSl и HTTP2

Добавляем следующие два фрагмента:

После %ip%:%proxy_ssl_port% в той же строке:

ssl http2

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

sudo nano /etc/nginx/nginx.conf

С марта 2020 года все популярные браузеры отключают поддержку TLS 1.0 и TLS 1.1, поэтому в примере приведу два варианта конфигурации.

Находим секцию #SSL PCI Compliance и редактируем в соответствии с моим листингом:

 add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
 add_header Content-Security-Policy-Report-Only "default-src https:; script-src https: 'unsafe-eval' 'unsafe-inline'; style-src https: 'unsafe-inline'; img-src https: data:; font-src https: data:; report-uri /csp-report";
 ssl_stapling on;
## ##Раскомментируйте если нужна поддержка старых протоколов
 #ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
## ## Закомментируйте если включили поддержку старых протоколов
 ssl_protocols TLSv1.2 TLSv1.3;
 ssl_prefer_server_ciphers on;
## ## Раскомментируйте для старых протоколов
 #ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
## ## Закомментируйте если включили поддержку старых протоколов
 ssl_ciphers "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-GCM-SHA512:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256";
 ssl_dhparam /home/admin/conf/web/dhparams.pem;
 ssl_session_tickets off;

Также нужно сгенерировать dhparams.pem и положить в нужную папку:

sudo openssl dhparam -out /home/admin/conf/web/dhparams.pem 4096

Вывод

Сегодня научились редактировать конфигурационный файл Web сервера Nginx в админ-панели VestaCP.

Также приведу пример полного конфигурационного файла для VestaCP и секцию SSL для Nginx:

Пример файла default.stpl

server {

listen %ip%:%proxy_ssl_port% ssl http2;
server_name %domain_idn% %alias_idn%;
ssl_certificate %ssl_pem%;
ssl_certificate_key %ssl_key%;
error_log /var/log/%web_system%/domains/%domain%.error.log error;
location / {     
      proxy_pass  https://%ip%:%web_ssl_port%;
      location ~* ^.+.(%proxy_extentions%)$ 
      {
          root %sdocroot%;
          access_log /var/log/%web_system%/domains/%domain%.log combined;
          access_log /var/log/%web_system%/domains/%domain%.bytes bytes;
          expires max;
          try_files $uri @fallback;
      }
}
location /error/ {
     alias %home%/%user%/web/%domain%/document_errors/;
}
location @fallback {
     proxy_pass https://%ip%:%web_ssl_port%;
}
location ~ /.ht {return 404;}
location ~ /.svn/ {return 404;}
location ~ /.git/ {return 404;}
location ~ /.hg/ {return 404;}
location ~ /.bzr/ {return 404;}
include %home%/%user%/conf/web/snginx.%domain%.conf*;

Пример файла nginx.conf

Привожу кусок файла nginx.conf непосредственно секцию SSL PCI Compliance

Включим параметр HSTS, OCSP, dhparam, а также поддержу TLSv1.2 и TLSv.1.3 и алгоритмы шифрования:

### SSL PCI Compliance ###
 ssl_session_cache   shared:SSL:10m;
 ssl_prefer_server_ciphers on;
 ssl_stapling on;
## ## Раскомментируйте если нужна поддержка старых протоколов
 #ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
## ## Закомментируйте если включили поддержку старых протоколов
 ssl_protocols TLSv1.2 TLSv1.3;
 ssl_prefer_server_ciphers on;
## ## Раскомментируйте для старых протоколов
 #ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
## ## Закомментируйте если включили поддержку старых протоколов
 ssl_ciphers "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-GCM-SHA512:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256";
 ssl_dhparam /home/admin/conf/web/dhparams.pem;
 ssl_session_tickets off;

После внесения данных изменений на сайте ssllab проверка будет показывать рейтинг A+ для ваших сайтов.

[endtxt]

Сегодня в статье разберём как включить OCSP на web-сервере Nginx с сертификатами от Let`s Encrypt.

Но сперва что же такое OCSP?

OCSP (Online Certificate Status Protocol) – это интернет протокол для проверки статуса SSL-сертификата, который работает быстрее и надежнее, чем это осуществлялось ранее с помощью списков САС (или CRL списков) с отозванными SSL сертификатами.

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

Метод OCSP Stapling помогает быстро и безопасно установить достоверность SSL-сертификата.

Извлекаем промежуточный сертификат Let’s Encrypt

Коннектимся под root:

sudo su

Скачиваем промежуточные сертификаты ЦА

cd /etc/ssl/private && wget -O - https://letsencrypt.org/certs/isrgrootx1.pem https://letsencrypt.org/certs/lets-encrypt-x1-cross-signed.pem https://letsencrypt.org/certs/letsencryptauthorityx1.pem https://www.identrust.com/certificates/trustid/root-download-x3.html | tee -a ca-certs.pem> /dev/null

Настройка OCSP stapling на Nginx с админ-панелью VestaCP

Отредактируйте файл виртуального хоста:

sudo nano /home/admin/conf/web/example.com.nginx.ssl.conf

и внесите в раздел server {} следующий блок кода:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/private/ca-certs.pem;

Перезагружаем nginx:

sudo /etc/init.d/nginx restart

Тестируем OCSP на Ubuntu Server

echo QUIT | openssl s_client -connect obu4alka.ru:443 -status 2> /dev/null | grep -A 17 'OCSP response:' | grep -B 17 'Next Update'

Данная команда выдаст следующий результат:

OCSP response:
================================================================ 
 OCSP Response Data:
     OCSP Response Status: successful (0x0)
     Response Type: Basic OCSP Response
     Version: 1 (0x0)
     Responder Id: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
     Produced At: Sep 14 01:40:00 2019 GMT
     Responses:
     Certificate ID:
       Hash Algorithm: sha1
       Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
       Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
       Serial Number: 03E2EA3D34CED68F180CD2179ABB275275C5
     Cert Status: good
     This Update: Sep 14 01:00:00 2019 GMT
     Next Update: Sep 21 01:00:00 2019 GMT

Онлайн-тест Qualys

Чтобы проверить работу OCSP stapling онлайн, перейдите на этот сайт. Когда тестирование будет завершено, найдите строку OCSP stapling в разделе Protocol Details.

Тестирование ALPN

testsite="obu4alka.ru"; echo | openssl s_client -alpn h2 -connect $testsite:443 -servername $testsite 2>&1 | grep -q "ALPN protocol: h2" && echo "ALPN поддерживается" || echo "ALPN не поддерживается"

либо так:

echo | openssl s_client -alpn h2 -connect obu4alka.ru:443 | grep ALPN

Можете также воспользоваться ещё одним способом проверки, вот ссылка

[endtxt]

RSS

Nginx – компактный и производительный веб-сервер, созданный для систем с высоким трафиком. Одной из его сильных сторон является эффективное представление статического контента, например, HTML или медиафайлов. В Nginx используется асинхронная модель с управлением событиями, что обеспечивает предсказуемую производительность при высокой нагрузке.

Динамический контент Nginx передает CGI, FastCGI или другим веб-серверам, например, Apache. Затем этот контент возвращается Nginx для отправки клиенту. В данном руководстве мы рассмотрим базовые принципы и параметры конфигурации Nginx.

Директивы, блоки и контексты

Все файлы конфигурации Nginx располагаются в директории /etc/nginx/. Основной файл конфигурации – /etc/nginx/nginx.conf.

Опции конфигурации Nginx называются директивами. Директивы организованы в группы, называемые блоками или контекстами (эти два понятия являются синонимами).

Строки, начинающиеся с символа «решетки» (#) – это комментарии. Они не интерпретируются Nginx. Строки с директивами должны оканчиваться на точку с запятой, иначе конфигурация не будет загружена, и вы получите сообщение об ошибке.

Ниже приведена сокращенная копия файла /etc/nginx/nginx.conf, который входит в состав установки. Он начинается с 4 директив: user, worker_processes, error_log, и pid. Они не входят в состав блока, поэтому говорят, что они находятся в контексте main. Блоки events и http содержат дополнительные директивы и также расположены в контексте main.

user nginx;

worker_processes 1;

error_log /var/log/nginx/error.log warn;

pid /var/run/nginx.pid;



events {

. . .

}



http {

. . .

}

Блок http

Блок http содержит директивы управления веб-трафиком. Они часто называются универсальными, потому что используются для конфигурации всех веб-сайтов, содержащихся на сервере. Полный список всех доступных директив и их параметров для этого блока можно посмотреть в документации Nginx. В /etc/nginx/nginx.conf можно увидить примерно следующий блок http

http {

include /etc/nginx/mime.types;

default_type application/octet-stream;

log_format main '$remote_addr - $remote_user [$time_local] "$request" '

'$status $body_bytes_sent "$http_referer" '

'"$http_user_agent" "$http_x_forwarded_for"';

access_log /var/log/nginx/access.log main;

sendfile on;

#tcp_nopush on;

keepalive_timeout 65;

#gzip on;

include /etc/nginx/conf.d/*.conf;

}

В рассмотренном примере заданы следующие директивы:

include – указывает расположение дополнительных файлов конфигурации

default_type – задает MIME-тип ответов по умолчанию

log_format – задает поля, которые будут сохраняться в логе сервера

access_log – путь к файлу лога доступа к серверу

sendfile – прямая передача данных без буферизации, используется для ускорения работы сервера

tcp_nopush – настройка формирования TCP-пакетов, ускоряющая работу сервера (в данном случае закомментировано)

keepalive_timeout – максимальное время поддержания соединения, если пользователь ничего не запрашивает

gzip – включение компрессии (в данном случае закомментировано)

• Как уже было сказано, блок http содержит директиву include, которая указывает расположение файлов конфигурации Nginx.
  
  Если установка выполнялась из официального репозитория Nginx, эта строка, как и в рассмотренном примере, будет иметь вид include /etc/nginx/conf.d/*.conf;. У каждого веб-сайта на вашем сервере в этой директории должен быть свой файл конфигурации с именем формата example.com.conf. Для отключенных сайтов (не отображаемых Nginx) он может быть переименован в формате example.com.conf.disabled.
• При установке из репозиториев Debian или Ubuntu данная строка будет иметь вид include /etc/nginx/sites-enabled/*;. Директория /sites-enabled/ содержит символические ссылки на файлы конфигурации, которые хранятся в /etc/nginx/sites-available/. Отключение сайта осуществляется удалением символической ссылки на sites-enabled.
• В зависимости от источника установки в /etc/nginx/conf.d/default.conf или /etc/nginx/sites-enabled/default есть пример файла конфигурации.

Серверные блоки

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

server {

listen 80 default_server;

listen [::]:80 default_server;

server_name example.com www.example.com;

root /var/www/example.com;

index index.html;

try_files $uri /index.html;

}

Директива server_name позволяет размещать несколько доменов на одном IP-адресе (виртуальные хосты). Выбор домена осуществляется на основании информации в заголовке полученного запроса.

Директива listen задает Nginx имя или IP-адрес узла и TCP-порт, который он должен прослушивать для HTTP-соединений. Аргумент default_server означает, что этот виртуальный хост будет отвечать на все запросы на порт 80, в которых в явном виде не будет указан другой виртуальный хост. Вторая такая директива устанавливает аналогичное поведение для IPv6-соединений.

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

1.Обработка запросов к example.com и www.example.com:

server_name example.com www.example.com;

2.В директиве server_name можно использовать маски. Например, *.example.com и .example.com указывают серверу обрабатывать запросы на все поддомены example.com:

server_name *.example.com;

server_name .example.com;

3.Обработка запросов ко всем доменным именам, начинающимся с example.:

server_name example.*;

Nginx разрешает указывать имена сервера, не соответствующие правилам доменных имен. Для ответа на запросы используется имя из заголовка HTTP вне зависимости от того, является ли оно допустимым доменным именем.

Это полезно, если ваш сервер работает в локальной сети или вы точно знаете все клиенты, которые будут осуществлять запросы, например, front-end прокси-серверы, у которых записи в /etc/hosts настроены на IP-адрес Nginx.

Блоки Location

Блоки location позволяют настроить, как Nginx будет отвечать на запросы к ресурсам на сервере. Подобно тому, как директива server_name определяет обработку запросов к доменам, директивы location охватывают запросы к конкретным файлам и папкам, таким как http://example.com/blog/. Вот несколько примеров:

location / { }

location /images/ { }

location /blog/ { }

location /planet/ { }

location /planet/blog/ { }

Указанные выше расположения – это точно определенные строки, которые соответствуют части HTTP-запроса после имени узла.

Запрос: http://example.com/

Ответ: Если для example.com есть запись server_name, обработка данного запроса будет определяться директивой location /.

Nginx всегда выполняет запрос, находя наиболее точное соответствие:

Запрос: http://example.com/planet/blog/ или http://example.com/planet/blog/about/

Ответ: Обработку запроса будет определять директива location /planet/blog/, потому что она соответствует точнее, хотя location /planet/ также удовлетворяет условиям запроса.

location ~ IndexPage.php$ { }

location ~ ^/BlogPlanet(/|/index.php)$ { }

Когда после директивы location указана тильда (~), Nginx определяет соответствие по регулярному выражению. Этот поиск всегда чувствителен к регистру. Таким образом, страница IndexPage.php будет соответствовать первому из приведенных выше примеров, а indexpage.php – нет. Во втором примере регулярному выражению будут соответствовать запросы к /BlogPlanet/ и /BlogPlanet/index.php, но не /BlogPlanet, /blogplanet/, или /blogplanet/index.php. В Nginx используются Perl-совместимые регулярные выражения.

Если вы хотите, чтобы поиск не был чувствителен к регистру, после тильды нужно указать звездочку (~*).

location ^~ /images/IndexPage/ { }

location ^~ /blog/BlogPlanet/ { }

Если указать перед тильдой символ «крышки» (^~), при соответствии запроса указанной строке сервер прекратит поиск более точных соответствий (даже если они есть) и будет использовать эти директивы. Во всем остальном они аналогичны рассмотренным выше директивам.

location = / { }

Знак равенства (=) после директивы location означает необходимость точного соответствия указанному пути. В случае его наличия поиск прекращается. Например, запрос http://example.com/ будет соответствовать указанному выше примеру, а http://example.com/index.html — нет. Использование точных соответствий может ускорить время обработки запроса, если какие-то запросы распространены больше других.

Директивы обрабатываются в следующем порядке:

1. Сначала обрабатываются точные соответствия строк. Если соответствие найдено, Nginx прекращает поиск и отвечает на запрос.
2. Обрабатываются оставшиеся директивы с точно заданными строками. Если Nginx находит соответствие директиве с аргументом ^~, он прекращает поиск и отвечает на запрос. В противном случае обработка директив location продолжается.
3. Обрабатываются директивы location с регулярными выражениями (~ и ~*). Если запрос соответствует регулярному выражению, Nginx прекращает поиск и отвечает на запрос.
4. Если соответствия регулярным выражениям не найдено, используется наиболее точное соответствие из жестко заданных строк.

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

Внутри блока location указываются собственные директивы, например:

location / {

root html;

index index.html index.htm;

}

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

Запрос: http://example.com/blog/includes/style.css

Ответ: Nginx попытается передать клиенту файл /etc/nginx/html/blog/includes/style.css

Переменная index сообщает Nginx, какой файл передавать, если клиент не указал конкретное имя, например:

Запрос: http://example.com

Ответ: Nginx попытается передать файл /etc/nginx/html/index.html.

Если в директиве index указано несколько файлов, Nginx пройдет по списку и передаст первый существующий файл. Если файла index.html в соответствующей директории нет, будет передан index.htm. В случае если ни один из файлов не существует, будет отправлено сообщение об ошибке 404.

Вот более сложный пример набора директив location для сервера example.com:

location / {

root /srv/www/example.com/public_html;

index index.html index.htm;

}

location ~ .pl$ {

gzip off;

include /etc/nginx/fastcgi_params;

fastcgi_pass unix:/var/run/fcgiwrap.socket;

fastcgi_index index.pl;

fastcgi_param SCRIPT_FILENAME /srv/www/example.com/public_html$fastcgi_script_name;

}

В данном примере все запросы ресурсов, которые заканчиваются на расширение .pl, будут обработаны вторым блоком location, в котором для ответа на эти запросы задан обработчик fastcgi. Ресурсы расположены в файловой системе /srv/www/example.com/public_html/. Если имя файла в запросе не указано, Nginx найдет и передаст файл index.html или index.htm. Если их нет, он выдаст ошибку 404.

Разберем ответы на некоторые запросы

Запрос: http://example.com/

Ответ: /srv/www/example.com/public_html/index.html если файл существует. Если нет, сервер передаст /srv/www/example.com/public_html/index.htm. Если и этот файл не существует, Nginx выдаст ошибку 404.

Запрос: http://example.com/blog/

Ответ: /srv/www/example.com/public_html/blog/index.html если файл существует. Если нет, сервер передаст /srv/www/example.com/public_html/blog/index.htm. Если и этот файл не существует, Nginx выдаст ошибку 404.

Запрос: http://example.com/tasks.pl

Ответ: Nginx воспользуется обработчиком FastCGI для выполнения файла /srv/www/example.com/public_html/tasks.pl и выдаст результат.

Запрос: http://example.com/username/roster.pl

Ответ: Nginx воспользуется обработчиком FastCGI для выполнения файла /srv/www/example.com/public_html/username/roster.pl и выдаст результат.

Заключение

Мы разобрали базовые принципы и параметры конфигурации веб-сервера Nginx. Этого достаточно, чтобы настроить простой сайт. Для более подробной информации о директивах файлов конфигурации стоит изучить официальную документацию Nginx.

Не всегда удобно пользоваться консолью MySQL для редактирования и создания баз данных. Поэтому многие устанавливают phpMyAdmin, но не знают как настроить PhpMyAdmin на NGINX в связке с PHP

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

Установка phpMyAdmin + Nginx в Ubuntu 18.04

Предположительно
у вас уже установлен MySQL сервер но еще не установлен phpMyAdmin.
Приступим к установке через терминал, putty и.т.д

sudo apt install phpmyadmin

В процессе установки будет предложено выбрать веб сервер на котором будет работать phpmyadmin. Так как устанавливать мы будем NGINX, то естественно мы просто нажмем enter и продолжим дальше. Далее будет предложено создать базу данных, и создать пароль для нее — выполните требуемое. 

Так как phpmyadmin распаковался и находится по пути /usr/share/phpmyadmin , а ваш сайт допусти лежит в директории /home/www/my.site.ru, то нам всего навсего нужно будет создать символьную ссылку таким образом:

ln -s /usr/share/phpmyadmin /home/www/my.site.ru

после
чего в директории сайта появится ссылка на менеджер управления базами
данных. И чтобы зайти в phpmyadmin нам нужно перейти по адресу:

http://my.site.ru/phpmyadmin/

Если вы не установили php 7.4 или другую версию php то phpmyadmin работать не будет

Установка php 7.4, php7.4-fpm и других расширений php

Вводим в терминале команду, которая установит все необходимые расширения для работы php движков:

sudo apt install php7.4 php7.4-fpm php7.4-mbstring php-pear php7.4-mcrypt php7.4-mysql php7.4-gd php7.4-zip php7.4-curl

После установки отредактируем php.ini

sudo nano /etc/php/7.4/fpm/php.ini

включаем поиск по файлу комбинацией клавиш ctrl+w. Вводим строку:

;cgi.fix_pathinfo = 1

раскомментируем и изменим 1 на 0. Чтобы выглядело вот так:

cgi.fix_pathinfo = 0

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

И так у нас все готово: расширение php для работы с mySQL установлены, установлен php-fpm для работы c nginx.

перейдем к следующему этапу настройки.

Настройка nginx для работы с phpmyadmin

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

sudo nano /etc/nginx/conf.d/my.site.conf

Вставим в него

server { 
listen 80;    
server_name my.site.ru;    
root /home/www/my.site.ru;    
charset utf-8;    
index index.php index.html;    
client_max_body_size 100m;    
fastcgi_read_timeout 160s; 

location / {    
try_files $uri $uri/ /index.php?$args;    
} 

location ~ .php$ {    
try_files $uri =404;    
fastcgi_index index.php;    
fastcgi_pass unix:/run/php/php7.4-fpm.sock;    
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;    
include fastcgi_params;    
} 
}

В данном случае вам будет доступен сайт если у вас он есть и phpmyadmin по адресу my.site.ru/phpmyadmin/ .

Если вы хотите чтобы менеджер баз данных был на другом домене, например mysql.my.site.ru, создайте в редакторе зон DNS вашего хостинга специальный поддомен и отредактируйте файл nginx так:

sudo nano /etc/nginx/conf.d/mysql.my.site.conf

server { 
listen 80;    
server_name mysql.my.site.ru;    
root /home/www/my.site.ru/phpmyadmin;    
charset utf-8;    
index index.php index.html;    
client_max_body_size 100m;    
fastcgi_read_timeout 160s; 

location / {    
try_files $uri $uri/ /index.php?$args;    
} 

location ~ .php$ {    
try_files $uri =404;    
fastcgi_index index.php;    
fastcgi_pass unix:/run/php/php7.4-fpm.sock;    
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;    include fastcgi_params;    
} 
}

Перезагружаем nginx и php fpm

sudo service php7.4-fpm restart

sudo service nginx restart

Теперь можно проверить все ли работает. На этом всё.

[endtxt]

RSS

Стек LEMP включает пакеты Nginx (Engine X), MySQL/MariaDB и PHP/Python, установленные в системе Linux и настроенные для совместной работы в качестве системы хостинга веб-сайтов, приложений или выполнения других функций. В данном руководстве мы рассмотрим установку стека LEMP на примере Ubuntu 18.04.

Для запуска рассмотренных команд потребуется доступ к серверу по SSH и root-привилегии (или использование команды sudo).

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

Обновите программные пакеты и установите Nginx при помощи менеджера пакетов apt-get. Nginx — быстрый, производительный и простой в настройке веб-сервер с открытым исходным кодом, поддерживающий функции балансировки нагрузки и обратного прокси.

$ sudo apt-get update

$ sudo apt-get install nginx

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

$ sudo systemctl status nginx

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

$ sudo systemctl start nginx

$ sudo systemctl enable nginx

Если в вашей системе есть брандмауэр, нужно открыть порты 80 (HTTP) и 443 (HTTPS), чтобы разрешить клиентам запросы на веб-сервер, а затем перезагрузить брандмауэр, например:

$ sudo ufw allow 80/tcp

$ sudo ufw allow 443/tcp

$ sudo ufw reload

Для проверки правильности работы ngnix нужно ввести в строке браузера имя или адрес вашего веб-сервера:

http://доменое_имя/

Или

http://IP-адрес_сервера/

Если установка была выполнена правильно, вы увидите тестовую страницу Nginx:

Установка MariaDB

Для установки системы управления базами данных MariaDB (разрабатываемая сообществом ветвь MySQL) выполните команду:

$ sudo apt-get install mariadb-server mariadb-client

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

$ sudo systemctl status mysql

Теперь нужно обеспечить минимальную безопасность базы данных при помощи специального скрипта (входит в комплект установки):

$ sudo mysql_secure_installation

Дайте ответ y (yes, да) на следующие вопросы, а также задайте пароль для пользователя root:

Set root password? [Y/n]: y

Remove anonymous users? (Press y|Y for Yes, any other key for No) : y

Disallow root login remotely? (Press y|Y for Yes, any other key for No) : y

Remove test database and access to it? (Press y|Y for Yes, any other key for No) : y

Reload privilege tables now? (Press y|Y for Yes, any other key for No) : y

Установка PHP

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

$ sudo apt-get install php php-fpm php-common php-mysql php-gd php-cli

После установки PHP служба PHP7.2-FPM (реализация FastCGI сервера) также должна запуститься автоматически. Это можно проверить следующей командой:

$ sudo systemctl status php7.2-fpm

Теперь нужно настроить PHP-FPM для правильного представления PHP-приложений или сайтов. Параметры конфигурации находятся в файле /etc/php/7.2/fpm/php.ini. Откройте его любым текстовым редактором:

$ sudo vim /etc/php/7.2/fpm/php.ini

Найдите строку ;cgi.fix_pathinfo=1 и замените ее на cgi.fix_pathinfo=0, чтобы при работе PHP рассматривал только указанный в явном виде путь и прекращал обработку, если файл не найден.

Затем в разделе серверного блока по умолчанию файла конфигурации сервера Nginx (/etc/nginx/sites-available/default) настройте обработку PHP-скриптов при помощи PHP-FPM:

$ sudo vim /etc/nginx/sites-available/default

Чтобы передавать PHP-скрипты серверу FastCGI, раскомментируйте следующий раздел:

location ~ .php$ {

include snippets/fastcgi-php.conf;

fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;

}

После внесения изменений перезапустите службы nginx и php7.2-fpm, чтобы они вступили в силу:

$ sudo systemctl restart php7.2-fpm

$ sudo systemctl restart nginx

Теперь можно проверить правильность настройки PHP, создав в корне документов вашего сервера простую страничку info.php. Для этого требуется всего одна команда:

echo "<?php phpinfo(); ?>" > /var/www/html/info.php

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

http://доменное_имя/info.php

или

http://IP-адрес_сервера/info.php

Заключение

Мы рассмотрели установку стека LEMP. Данный набор является платформой, на которую могут устанавливаться веб-сайты и веб-приложения. Для более подробной информации обратитесь к соответствующим man-страницам.