Установка производных переменных окружения
Скрипт в строках 55-61 выставляет следующие переменные окружения, либо в некоторое жестко заданное значение, либо с применением значения, полученного из переменных, установленных в предыдущем разделе:
- — сообщает приложениям, что они запускаются в скрипте и нет возможности взаимодействия с пользователем.
- — версия приложения WordPress CLI.
- — контрольная сумма исполняемого файла WordPress CLI 2.4.0 (версия указывается в переменной ). Скрипт на 162 строке использует это значение для проверки, что был скачан корректный файл WordPress CLI.
- — максимальный размер файла, который может быть закачан в WordPress. Эта настройка используется в нескольких местах, так что проще задавать ее в одном месте.
- — hostname системы, извлекаемый из переменной WORDPRESS_URL. Используется для получения соответствующих TLS/SSL сертификатов от Let’s Encrypt, а также для внутренней проверки WordPress.
- — путь к каталогу с настройками NGINX, включая основной файл .
- — путь к сертификатам Let’s Encrypt для сайта WordPress, получаемый из переменной .
Шаг 7. Обработка нескольких PHP-файлов одновременно
К сожалению, PHP в Windows не умеет создавать копии своих экземпляров, поэтому придётся заранее запускать несколько копий и описать их использование в конфиге nginx.
В файле start.cmd пропишите запуск php-cgi.exe на разные номера портов:
%SRVPATH%\RunHiddenConsole.exe %SRVPATH%\php\php-cgi.exe -b 127.0.0.1:9000 -c %SRVPATH%/php/php.ini %SRVPATH%\RunHiddenConsole.exe %SRVPATH%\php\php-cgi.exe -b 127.0.0.1:9001 -c %SRVPATH%/php/php.ini %SRVPATH%\RunHiddenConsole.exe %SRVPATH%\php\php-cgi.exe -b 127.0.0.1:9002 -c %SRVPATH%/php/php.ini %SRVPATH%\RunHiddenConsole.exe %SRVPATH%\php\php-cgi.exe -b 127.0.0.1:9003 -c %SRVPATH%/php/php.ini %SRVPATH%\RunHiddenConsole.exe %SRVPATH%\php\php-cgi.exe -b 127.0.0.1:9004 -c %SRVPATH%/php/php.ini
Запустите столько процессов, сколько вам потребуется (обычно достаточно 5-20). В нашем примере используется 5 экземпляров с номерами портов 9000 — 9004.
Откройте файл nginx.conf в текстовом редакторе и перед директивой server {} пропишите следующие строки:
upstream backend { server 127.0.0.1:9000; server 127.0.0.1:9001; server 127.0.0.1:9002; server 127.0.0.1:9003; server 127.0.0.1:9004; }
Теперь откройте файл fastcgi_params и в самом начале пропишите следующее:
fastcgi_connect_timeout 1; fastcgi_next_upstream timeout; fastcgi_pass backend;
Обязательно уберите fastcgi_pass 127.0.0.1:9000; во всех директивах location.
Пример готового конфига nginx.conf:
worker_processes 4; error_log logs/error.log; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; gzip on; upstream backend { server 127.0.0.1:9000; server 127.0.0.1:9001; server 127.0.0.1:9002; server 127.0.0.1:9003; server 127.0.0.1:9004; } server { listen 80 default; server_name localhost; server_tokens off; location / { root C:/nginx/public_html; index index.html index.htm index.php; location ~ \.php$ { include fastcgi_params; } } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } location ~ /\.ht { deny all; } } }
Пример конфига, использующего SSL:
worker_processes 4; error_log logs/error.log; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; gzip on; upstream backend { server 127.0.0.1:9000; server 127.0.0.1:9001; server 127.0.0.1:9002; server 127.0.0.1:9003; server 127.0.0.1:9004; } server { listen 443 default; server_name localhost; server_tokens off; ssl on; ssl_certificate C:/nginx/private/ssl_cert_domain.pem; ssl_certificate_key C:/nginx/private/ssl_cert_domain.key; ssl_session_timeout 5m; ssl_protocols SSLv2 SSLv3 TLSv1; ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP; ssl_prefer_server_ciphers on; location / { root C:/nginx/public_html; index index.html index.htm index.php; location ~ \.php$ { include fastcgi_params; fastcgi_param HTTPS on; } } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } location ~ /\.ht { deny all; } } }
Пример файла fastcgi_params:
fastcgi_connect_timeout 1; fastcgi_next_upstream timeout; fastcgi_pass backend; fastcgi_param QUERY_STRING $query_string; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_param SCRIPT_NAME $fastcgi_script_name; fastcgi_param REQUEST_URI $request_uri; fastcgi_param DOCUMENT_URI $document_uri; fastcgi_param DOCUMENT_ROOT $document_root; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param SERVER_PROTOCOL $server_protocol; fastcgi_param HTTPS $https if_not_empty; fastcgi_param GATEWAY_INTERFACE CGI/1.1; fastcgi_param SERVER_SOFTWARE nginx/$nginx_version; fastcgi_param REMOTE_ADDR $remote_addr; fastcgi_param REMOTE_PORT $remote_port; fastcgi_param SERVER_ADDR $server_addr; fastcgi_param SERVER_PORT $server_port; fastcgi_param SERVER_NAME $server_name; # PHP only, required if PHP was built with --enable-force-cgi-redirect fastcgi_param REDIRECT_STATUS 200; fastcgi_index index.php;
Настройка виртуальных хостов
Как вы знаете, на сервере может размещаться несколько сайтов. Все запросы приходят на ip сервера, а nginx уже определяет на основе домена какой контент нужно выдать. Для того чтобы nginx знал что к какому домену относится нужно настроить виртуальные хосты. Каждый хост принято размещать в отдельном файле. Настройка хоста находится в секции server, но поскольку все файлы из sites-enabled импортируются в секцию http, то логика структуры конфигурационного файла не нарушается.
Рассмотрим пример настройки:
- listen 80 — указывает, что нужно ожидать подключения на порту 80, может также содержать опцию default-server, которая означает, что этот домен будет открывается если домен не был задан в запросе.
- root /var/www/html — директория, в которой находятся файлы сайта.
- index index.html — страница, которая будет открываться по умолчанию.
- server_name — доменное имя сайта.
- access_log — файл для записи лога запросов к серверу, может использоваться как глобально в секции http, так и для определенного типа файлов в location.
- error_log — лог ошибок веб-сервера, может принимать дополнительный параметр, указывающий подробность лога. warn — максимум, crit — только критические ошибки.
Это все основные настройки виртуального хоста, после них он уже будет работать. Но тут есть еще секция location, которая позволяет настроить поведение сервера для определенных директорий и файлов. Синтаксис location такой:
location адрес {}
В качестве адреса может использоваться как прямой запрос относительно корня сервера, так и регулярные выражения. Для использования регулярных выражений перед ним ставится символ «~». Примеры рассмотрим ниже, а пока рассмотрим возможные директивы:
- allow — разрешить доступ к местоположению для пользователей, all — всех, также можно указать ip или подсеть.
- deny — запретить доступ к местоположению, all — для всех.
- try-files — пытается открыть файлы в определенном порядке, открывает первый обнаруженный файл. Например, такая конструкция: $uri $uri/index.html $uri.html =404; сначала пытается открыть $uri, затем index.html, если не найден $uri.html, и аж потом, если ни одного из предложных файлов не существует, выдает ошибку 404.
- expires — задает время кэширования браузером отданного элемента, например, 1d — один день, 2h — два часа, 30s — 30 секунд.
Кроме этих главных директив, здесь могут использоваться и другие. Чтобы получить больше подробностей, смотрите официальную документацию. Рассмотрим пару примеров:
Не выполнять логирование для favicon:
Запретить доступ к файлам, начинающимся с точки:
Кэшировать обычные файлы на 90 дней:
После того, как установка и настройка nginx будет завершена проверяем конфигурацию на ошибки:
Затем перезагружаем сервер:
Если изменялись незначительные параметры можно использовать reload, тогда будет просто обновлена конфигурация без перезагрузки, если же изменяли глобальные опции, нужно перезагрузить программу полностью с помощью restart.
О данной инструкции¶
Nginx изначально умел очень мало и позиционировался как быстрый http-сервер для отдачи статики. Cейчас он умеет почти все, что и Apache. При этом первый менее ресурсоемкий и гораздо проще в настройке.
Выполнять его установку и настройку будем на дистрибутиве CentOS 7, который часто использутеся в качестве серверной ОС. Для других дистрибутивов процесс практически идентичен. Вам будет необходимо подключиться по () к хосту на порт , где XX — номер вашего компьютера. Заходите под пользователем root с паролем toor. Пароль можно сразу изменить ().
К слову, сайт школы работает именно на такой конфигурации: Nginx и CentOS 7.
Шаг 4. Настройка Nginx для работы с PHP
Для настройки Nginx откроем для редактирования файл серверных настроек:
sudo nano /etc/nginx/sites-available/default
В данном файле нам нужно внести несколько изменений:
- добавить в директиву «index» значение «index.php» первым в списке (чтобы PHP файлы имели приоритет в обработке веб-сервером перед HTML);
- установить директиву «server_name» в значение IP адреса (или доменного имени) нашего сервера;
- раскомментировать секцию, которая описывает настройки обработки PHP.
Результирующий файл серверных настроек представлен ниже:
server { listen 80 default_server; listen :80 default_server; root /var/www/html; index index.php index.html index.htm index.nginx-debian.html; server_name IP_адрес_сервера_или_доменное_имя; location / { try_files $uri $uri/ =404; } location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php7.0-fpm.sock; }}
Сохраните отредактированный файл («Ctrl + o») и выйдите из редактора («Ctrl + x»).
Чтобы изменения вступили в силу, перезапустим Nginx:
sudo systemctl restart nginx
Настройка NGINX Unit
Скрипт настраивает NGINX Unit для запуска PHP и обработки путей WordPress, изолируя пространство имен процессов PHP и оптимизируя настройки производительности
Тут есть три функции, на которые стоит обратить внимание:
- Поддержка пространств имен определяется по условию, основана на проверке запуска скрипта в контейнере. Это нужно, поскольку большинство настроек контейнеров не поддерживают вложенный запуск контейнеров.
- Если есть поддержка пространств имен, отключается пространство имен network. Это нужно, чтобы позволить WordPress одновременно подключаться и к endpoints и быть доступным в интернете.
- Максимальное число процессов определяется следующим образом: (Доступная память для запущенных MariaDB и NGINX Uniy)/(предел по оперативной памяти в PHP + 5)
Это значение устанавливается в настройках NGINX Unit.
Также это значение подразумевает, что всегда есть как минимум два запущенных процесса PHP, что важно, поскольку WordPress делает много асинхронных запросов к самому себе, а без дополнительных процессов запуск, к примеру, WP-Cron, сломается. Вы, возможно, захотите увеличить или уменьшить эти ограничения, основываясь на ваших локальных настройках, потому что созданные настройки здесь — консервативные
На большинстве производственных систем настройки находятся между 10 и 100.
nginx: документация
- Установка nginx
- Сборка nginx из исходных файлов
- Руководство для начинающих
- Руководство администратора
- Управление nginx
- Методы обработки соединений
- Настройка хэшей
- Отладочный лог
- Запись в syslog
- Единицы измерения в конфигурационном файле
- Параметры командной строки nginx
- nginx под Windows
- Как nginx обрабатывает запросы
- Имена сервера
-
Балансировка HTTP
с помощью nginx - Настройка HTTPS-серверов
Как nginx обрабатывает TCP/UDP-сессии
Создание сценариев на njs
Глава “nginx” из книги
“The Architecture of Open Source Applications”
-
Сборка nginx
на платформе Win32 компилятором Visual C - Настройка окружения NGINX Plus на Amazon EC2
-
Отладка
nginx с помощью DTrace pid provider
-
Преобразование
rewrite-правил - Проксирование WebSocket
- Внесение изменений
-
Руководство
по разработке
- Алфавитный указатель директив
- Алфавитный указатель переменных
Основная функциональность
-
ngx_http_core_module
-
ngx_http_access_module
-
ngx_http_addition_module
-
ngx_http_api_module
-
ngx_http_auth_basic_module
-
ngx_http_auth_jwt_module
-
ngx_http_auth_request_module
-
ngx_http_autoindex_module
-
ngx_http_browser_module
-
ngx_http_charset_module
-
ngx_http_dav_module
-
ngx_http_empty_gif_module
-
ngx_http_f4f_module
-
ngx_http_fastcgi_module
-
ngx_http_flv_module
-
ngx_http_geo_module
-
ngx_http_geoip_module
-
ngx_http_grpc_module
-
ngx_http_gunzip_module
-
ngx_http_gzip_module
-
ngx_http_gzip_static_module
-
ngx_http_headers_module
-
ngx_http_hls_module
-
ngx_http_image_filter_module
-
ngx_http_index_module
-
ngx_http_js_module
-
ngx_http_keyval_module
-
ngx_http_limit_conn_module
-
ngx_http_limit_req_module
-
ngx_http_log_module
-
ngx_http_map_module
-
ngx_http_memcached_module
-
ngx_http_mirror_module
-
ngx_http_mp4_module
-
ngx_http_perl_module
-
ngx_http_proxy_module
-
ngx_http_random_index_module
-
ngx_http_realip_module
-
ngx_http_referer_module
-
ngx_http_rewrite_module
-
ngx_http_scgi_module
-
ngx_http_secure_link_module
-
ngx_http_session_log_module
-
ngx_http_slice_module
-
ngx_http_spdy_module
-
ngx_http_split_clients_module
-
ngx_http_ssi_module
-
ngx_http_ssl_module
-
ngx_http_status_module
-
ngx_http_stub_status_module
-
ngx_http_sub_module
-
ngx_http_upstream_module
-
ngx_http_upstream_conf_module
-
ngx_http_upstream_hc_module
-
ngx_http_userid_module
-
ngx_http_uwsgi_module
-
ngx_http_v2_module
-
ngx_http_xslt_module
-
ngx_mail_core_module
-
ngx_mail_auth_http_module
-
ngx_mail_proxy_module
-
ngx_mail_realip_module
-
ngx_mail_ssl_module
-
ngx_mail_imap_module
-
ngx_mail_pop3_module
-
ngx_mail_smtp_module
-
ngx_stream_core_module
-
ngx_stream_access_module
-
ngx_stream_geo_module
-
ngx_stream_geoip_module
-
ngx_stream_js_module
-
ngx_stream_keyval_module
-
ngx_stream_limit_conn_module
-
ngx_stream_log_module
-
ngx_stream_map_module
-
ngx_stream_proxy_module
-
ngx_stream_realip_module
-
ngx_stream_return_module
-
ngx_stream_set_module
-
ngx_stream_split_clients_module
-
ngx_stream_ssl_module
-
ngx_stream_ssl_preread_module
-
ngx_stream_upstream_module
-
ngx_stream_upstream_hc_module
-
ngx_stream_zone_sync_module
ngx_google_perftools_module
Оптимизация работы соединений
Настроим несколько основных параметров, которые отвечают за количество обрабатываемых соединений и сроки их поддержания.
— Определяет количество рабочих процессов. Обычно, выставляют равному числу ядер, но в новых версиях его лучше устанавливать в auto. По умолчанию 1
— Устанавливает максимальное количество соединений одного рабочего процесса, то есть nginx будет обрабатывать * , остальные запросы ставить в очередь. Следует выбирать значения от 1024 до 4096. По умолчанию 512.
— Позволяет принимать максимально возможное количество соединений. Иначе, процесс nginx за один раз будет принимать только одно новое соединение. По умолчанию off.
— Отвечает за максимальное время поддержания keepalive-соединения, в случае, если пользователь по нему ничего не запрашивает. Для современных систем, стоит выставить от 30 до 50. В нашем случае 45. По умолчанию 75.
— Если клиент перестал читать страницу, Nginx будет сбрасывать соединение с ним. По умолчанию off.
— Ждет выставленное количество секунд тело запроса от клиента, после чего сбрасывает соединение. По умолчанию 60.
— Если клиент прекратит чтение ответа, Nginx подождет выставленное количество секунд и сбросит соединение. По умолчанию 60.
Установка и настройка Nginx
Выполните установку Nginx:
emerge -a www-servers/nginx
Настройка Nginx
Все настройки Nginx прописываются в файле . Параметры для сайтов хранятся в каталоге .
Запустите Nginx:
/etc/init.d/nginx start
Добавьте Nginx в автозагрузку:
rc-update add nginx
Пример настройки Nginx
Создайте файл настроек для :
/etc/nginx/sites-enabled/local.conf
server { listen 80; server_name localhost; access_log /var/log/nginx/localhost.access_log main; error_log /var/log/nginx/localhost.error_log info; root /var/calculate/www/localhost/htdocs; }
Создайте индексный файл для проверки работоспособности сервера:
mkdir -p /var/calculate/www/localhost/htdocs
echo ‘Hello!’ > /var/calculate/www/localhost/htdocs/index.html
Проверка настроек
Перед тем, как перезапускать службу Nginx, всегда выполняйте проверку правильности сделанных изменений командой
Если всё верно, то будет выведено следующее:
nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful
После успешной проверки перечитайте конфигурацию Nginx:
/etc/init.d/nginx reload
Чтобы проверить, что Nginx работает и есть доступ, воспользуйтесь консольным веб-клиентом :
curl http://localhost
Hello!
Настройка HTTPS для Nginx
Сгенерируйте ключ для протокола Диффи-Хеллмана:
openssl dhparam -out /etc/nginx/ssl-dhparams.pem 4096
Generating DH parameters, 4096 bit long safe prime, generator 2 This is going to take a long time
Создайте файл описания общих параметров SSL:
/etc/nginx/ssl.conf
# This file contains important security parameters. If you modify this file # manually, Certbot will be unable to automatically provide future security # updates. Instead, Certbot will print and log an error message with a path to # the up-to-date file that you will need to refer to when manually updating # this file. ssl_session_cache shared:le_nginx_SSL:1m; ssl_session_timeout 1440m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; ssl_ciphers "ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS"; ssl_dhparam /etc/nginx/ssl-dhparams.pem;
Получите сертификат доменов www.example.org и example.org для Nginx, следуя руководству.
Пример настроки HTTPS
Добавьте настройки HTTPS для example.org:
/etc/nginx/sites-enabled/example.org.conf
server { listen 80; listen 443 ssl; server_name www.example.org example.org; include ssl.conf; ssl_certificate /etc/letsencrypt/live/example.org/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.org/privkey.pem; access_log /var/log/nginx/example.org.access_log main; error_log /var/log/nginx/example.org.error_log info; include acme.conf; root /var/calculate/www/example.org/htdocs; }
Перенаправление с HTTP на HTTPS
Добавьте правило перенаправления запросов с http://example.org на https://example.org:
/etc/nginx/sites-enabled/example.org.conf
server { listen 80; listen 443 ssl; server_name www.example.org example.org; include ssl.conf; ssl_certificate /etc/letsencrypt/live/example.org/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.org/privkey.pem; access_log /var/log/nginx/example.org.access_log main; error_log /var/log/nginx/example.org.error_log info; include acme.conf; if ($scheme = http) { return 301 https://$server_name$request_uri; } root /var/calculate/www/example.org/htdocs; }
Настройка серверных блоков NGINX
Если вы хотите разместить несколько веб-сайтов на одном веб-сервере NGINX, то вам нужно будет настроить серверные блоки. Серверные блоки также называются виртуальными хостами (в основном в Apache).
NGINX предварительно сконфигурирован только с одним блоком сервера. И именно там хранятся сведения о конфигурации для веб—сайта по умолчанию (/etc/nginx/sites-available) (/var/www/html).
Давайте посмотрим:
Выполните следующую команду, для того чтоб отобразить содержимое файла блока сервера по умолчанию.
Нажмите пробел на клавиатуре, чтобы прокрутить страницу вниз. Вы увидите сведения о конфигурации сервера по умолчанию. Например такие данные как номер порта прослушивания, корневой каталог документа (т. е. базовая папка для хранения содержимого веб-сайта), индексный файл и имя сервера.
Вы также должны увидеть раздел под названием конфигурация виртуального хоста, как показано ниже.
Вы можете настроить свой дополнительный веб-сайт здесь, но лучше создать отдельный файл блока сервера и оставить файл по умолчанию как есть.
А пока скопируйте приведенный выше пример конфигурации и сохраните его в текстовом редакторе. Так как мы будем использовать эту информацию в ближайшее время.
Создать корень сайта
Далее вам нужно будет создать корневую папку в разделе /var / www . Это делается для хранения содержимого вашего дополнительного веб-сайта. Например, я собираюсь создать папку с именем domain1.com.
Создание индексного файла
Индексный файл — это главная веб-страница, которая отображается при открытии веб-сайта. Выполните следующую команду, чтобы создать индексный файл для вашего дополнительного веб-сайта.
В этом примере я использую nano, но вы можете использовать свой любимый текстовый редактор. Вы можете скопировать и вставить следующий HTML код для тестирования.
Сохраните изменения и закройте текстовый редактор.
Создание серверного блока
Следующим шагом является создание файла серверного блока. Предназначен он для хранения сведений о конфигурации дополнительного веб-сайта. Выполните следующую команду.
Скопируйте пример конфигурации виртуального хоста сохраненного ранее и вставьте его в новый файл. Начиная со строки «server», убедитесь, что вы удалили все символы #. Чтобы раскомментировать директивы. Кроме того, не забудьте заменить “domain1” на ваше собственное зарегистрированное доменное имя соответственно.
Сохраните изменения и закройте этот файл.
Включить серверный блок
Чтобы NGINX знал, что дополнительный веб-сайт доступен, выполните следующую команду для создания символической ссылки на файл блока сервера.
Проверьте свою конфигурацию
Запустите sudo nginx-t, чтобы проверить конфигурацию блока сервера. Вы должны увидеть сообщение, указывающее, что все в порядке.
Вы можете запустить sudo service nginx reload, чтобы перезагрузить файлы конфигов.
Протестируйте свой новый сайт
Откройте веб-браузер и введите свой новый адрес веб-сайта. Вы должны увидеть содержимое индексного файла, созданного для вашего нового веб-сайта. А не веб-страницу NGINX по умолчанию.
Хостинг дополнительного сайта с использованием серверного блока
Установка и настройка FTP-сервера
Мы настроим ProFTPd, так как он позволит использовать виртуальных пользователей с uid пользователя www-data.
Для его установки вводим следующую команду:
apt-get install proftpd
Смотрим uid пользователя www-data:
id www-data
* в Ubuntu это, как правило, 33.
Создаем виртуального пользователя:
ftpasswd —passwd —file=/etc/proftpd/ftpd.passwd —name=ftpwww —uid=33 —gid=33 —home=/var/www —shell=/usr/sbin/nologin
* где /etc/proftpd/ftpd.passwd — путь до файла, в котором хранятся пользователи; ftpwww — имя пользователя (логин); uid и gid — идентификаторы пользователя и группы системной учетной записи (www-data); /var/www — домашний каталог пользователя; /usr/sbin/nologin — оболочка, запрещающая локальный вход пользователя в систему.
Открываем основной конфигурационный файл:
vi /etc/proftpd/proftpd.conf
Снимаем комментарий или редактируем опцию:
DefaultRoot ~
* данная опция говорит о том, что корневой директорией для пользователя будет домашняя директория. Это нужно, чтобы FTP-пользователи не могли выйти за пределы дозволенного и видеть на сервере сайты друг друга.
Создаем дополнительный конфигурационный файл для proftpd:
vi /etc/proftpd/conf.d/custom.conf
Со следующим содержимым:
UseIPv6 off
IdentLookups off
PassivePorts 60000 65535
RequireValidShell off
AuthUserFile /etc/proftpd/ftpd.passwd
AuthPAM off
LoadModule mod_auth_file.c
AuthOrder mod_auth_file.c
* где 60000 — 65535 — диапазон динамических портов для пассивного режима.
Разрешаем автозапуск FTP-серверу и запускаем его:
systemctl enable proftpd
systemctl restart proftpd
Пробуем подключиться к серверу, использую любые FTP-клиенты, например, FileZilla, Total Commander или тот же браузер.
При необходимости, можно настроить шифрование и хранение пользователей в базе данных. Подробнее в инструкции Установка и настройка ProFTPd на Ubuntu Server.
Настройка виртуального хоста Nginx
Вообще, у Nginx только один конфигурационный файл — это /etc/nginx/nginx.conf. Все остальные файлы из папки /etc/nginx/* подключаются в этот файл с помощью директивы include. Поэтому теоретически все виртуальные хосты или только часть из них могут быть размещены в этом файле. Однако так делать не рекомендуется.
Для этого уже существует папка /etc/nginx/sites-available/ и /etc/nginx/sites-enabled. Первая просто содержит файлы конфигурации, в каждом из которых находится отдельный виртуальный хост. Вторая папка содержит ссылки на файлы из /etc/nginx/sites-available и подключена к основному конфигурационному файлу. Даже если в вашей системе пока такая структура не используется, я рекомендую её создать, чтобы в конфигурации всегда был порядок.
1. Синтаксис виртуального хоста
Каждый виртуальный хост представляет из себя такой блок кода:
server { listen ip_адрес:порт; server_name доменные_имена; root /путь/к/файлам/сайта/; index index.php index.html; …. location / {} ….}
Кроме того, здесь могут использоваться и другие инструкции, но эти основные и обязательные.
- listen — указывает на IP-адрес и порт, на котором программа будет ожидать соединения от этого сайта. Чтобы выбрать любой IP-адрес, можно указать звёздочку, а порт указывать обязательно. Также в этой строке можно добавить параметр default_server, тогда этот виртуальный хост будет использоваться по умолчанию;
- server_name — доменные имена, на которые будет отзываться этот хост. При отправке запроса на сервер, браузер указывает, к какому домену он обращается. Nginx анализирует этот параметр и выбирает необходимый виртуальный хост. Чтобы обрабатывать все домены, используйте символ подчеркивания _;
- root — путь к файлам сайта, которые будут открываться при запросе к этому виртуальному хосту. У Nginx должен быть доступ на чтение ко всем папкам по этому пути;
- index — файлы, которые будут открываться, если адрес файла не указан в URL;
- location — это набор правил обработки путей в url. Каждый location может содержит путь URL а внутри него можно настроить открытие другого файла, аутентификацию, запрос к другому серверу и другие подобные вещи. Nginx анализирует все location в конфигурационном файле и выбирает самое подходящее. Из этого правила есть одно исключение. Если несколько location содержат регулярные выражения, то для обработки будет выбран первый подходящий.
2. Виртуальный хост по умолчанию
Теперь разберём создание виртуальных хостов nginx на примере. Давайте создадим виртуальный хост, который будет обрабатывать все необработанные запросы:
Все директивы, которые используются в блоке server, могут использоваться и в блоках location. Но нам не обязательно указывать root и index в каждом location. Если их опустить, то будут наследоваться те, которые были указаны в родительском блоке. Блоки server ведут себя аналогичным образом, поэтому, если мы не укажем другой путь к access.log, то будет использоваться путь, указанный в /etc/nginx/nginx.conf и так далее.
Теперь нам нужно активировать созданный виртуальный хост nginx. Для этого создайте символическую ссылку:
Затем убедитесь, что файлы из этого каталога подключены в основном конфигурационном файле:
Затем выполните эту команду, чтобы убедится, что вы не допустили ошибок:
Далее перечитайте конфигурацию nginx:
Теперь, если вы откроете IP-адрес сервера, то откроется созданный нами виртуальный хост.
2. Виртуальный хост с доменом
Аналогичным образом можно создать виртуальный хост для домена. Например example.ru:
Если вы работаете на локальной машине и доступа к DNS выбранного домена у вас нет, то надо добавить его IP в файл /etc/hosts:
Повторите процедуру активации домена, и затем в браузере при запросе к домену example.ru откроется стартовая страница Nginx. Если по каким-либо причинам виртуальный хост Nginx не работает, вы можете посмотреть полный скомпилированный файл nginx.conf:
Также можно проверить, есть ли в нём конфигурация нужного хоста, например, ищем упоминания example.ru:
3. Отключение виртуального хоста
Благодаря структуре директорий, которую мы использовали, будет довольно просто отключить ненужный хост. Все наши виртуальные хосты Nginx находятся в папке /etc/nginx/sites-available, а в активной папке только ссылки на эти файлы. Поэтому для удаления достаточно удалить на него ссылку из папки /etc/nginx/sites-enabled/:
А затем, при необходимости, мы можем активировать его обратно, просто создав ссылку.