Не запускается nginx ubuntu
Обновлено: 04.07.2024
Nginx – это один из популярнейших веб-серверов в мире, позволяющий размещать очень большие сайты с высоким трафиком. Он обычно расходует меньше ресурсов, чем другие веб-серверы, а еще может работать как обратный прокси-сервер.
Данный мануал поможет установить Nginx на сервер Ubuntu 20.04. также вы узнаете, как разблокировать трафик Nginx в брандмауэре, управлять этим сервисом и настроить блок server (аналог виртуального хоста).
Требования
Для работы нужен сервер Ubuntu 20.04, настроенный по этому мануалу.
1: Установка Nginx
Пакет Nginx можно найти в стандартном репозитории Ubuntu и установить с помощью пакетного менеджера apt.
Если это ваше первое взаимодействие с системой пакетирования apt в текущей сессии, вы должны обновить индекс пакетов. После этого можно установить Nginx.
sudo apt update
sudo apt install nginx
Чтобы подтвердить установку, нажмите Enter. После этого пакетный менеджер установит Nginx и его зависимости.
2: Настройка брандмауэра
Прежде чем протестировать Nginx, нужно разблокировать его трафик в брандмауэре ufw. Во время установки Nginx регистрирует в ufw профиль своего сервиса, потому открыть его трафик будет несложно.
Откройте список доступных профилей ufw:
В этом списке вы найдете три профиля Nginx:
Лучше использовать профиль, который поддерживает шифрование. Но поскольку на свежем сервере ещё не настроен SSL, мы можем открыть только порт 80.
Чтобы включить соответствующий профиль, введите:
Убедитесь в том, что профиль включился:
sudo ufw status
3: Тестирование веб-сервера
После установки Ubuntu 20.04 запустит Nginx автоматически. На данный момент веб-сервер должен работать.
Чтобы убедиться в том, что Nginx запустился, запросите его состояние в системе инициализации systemd.
systemctl status nginx
nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2020-04-20 16:08:19 UTC; 3 days ago
Docs: man:nginx(8)
Main PID: 2369 (nginx)
Tasks: 2 (limit: 1153)
Memory: 3.5M
CGroup: /system.slice/nginx.service
├─2369 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
└─2380 nginx: worker process
Как видите, сервис запущен успешно.
Также для проверки можно посетить стандартную посадочную страницу Nginx. Она доступна в браузере по домену или IP-адресу.
Если вы не знаете своего IP-адреса, вы можете узнать его с помощью командной строки. Введите:
Узнав свой IP-адрес, введите его в браузер, чтобы убедиться, что веб-сервер работает должным образом.
На экране должна появиться стандартная страница Nginx:
Welcome to nginx!
If you see this page, the nginx web server is successfully installed and working. Further configuration is required.
4: Управление процессами Nginx
Теперь давайте рассмотрим несколько базовых команд для управления сервисом Nginx.
Чтобы остановить Nginx, введите:
sudo systemctl stop nginx
Чтобы запустить его, введите:
sudo systemctl start nginx
Для перезапуска веб-сервера используйте команду:
sudo systemctl restart nginx
Чтобы обновить настройки Nginx, не сбрасывая соединения, введите команду:
sudo systemctl reload nginx
По умолчанию Nginx автоматически запускается во время загрузки сервера. Это поведение можно отключить:
sudo systemctl disable nginx
Чтобы возобновить автозапуск сервиса, введите:
sudo systemctl enable nginx
5: Настройка виртуального хоста
Затем установите права на каталог с помощью переменной $USER:
Права должны быть установлены верно, если вы не поменяли unmask, но на всякий случай вы можете ввести такую команду:
Затем создайте образец страницы index.html с помощью nano или другого редактора:
Сохраните и закройте файл.
Вставьте в файл следующие конфигурации. Они похожи на конфигурации по умолчанию, но содержат правильный домен и каталог:
Обратите внимание, что root содержит путь к новому каталогу, а server_name – новый домен.
Сохраните и закройте файл.
Включите файл, создав симлинк в каталоге sites-enabled:
Теперь у вас есть два виртуальных хоста, которые будут обслуживать запросы клиентов на основе директив listen и server_name:
Чтобы избежать проблем с памятью, которые могут возникнуть в результате настройки дополнительных имен серверов, необходимо отредактировать одно значение в файле /etc/nginx/nginx.conf. Откройте файл:
sudo nano /etc/nginx/nginx.conf
Сохраните и закройте файл.
Проверьте ошибки в конфигурационном файле Nginx:
Перезапустите Nginx, чтобы новые параметры вступили в силу:
sudo systemctl restart nginx
6: Важные файлы и каталоги Nginx
Теперь вы знаете, как управлять сервисом. Пора познакомиться с важными файлами и каталогами веб-сервера Nginx.
Контент
- /var/www/htm: содержит текущий контент сайта. По умолчанию в нём находится только стандартная посадочная страница, которую вы уже видели. Этот каталог можно изменить в конфигурационном файле Nginx.
Настройки сервера
Заключение
Теперь веб-сервер Nginx установлен и готов к работе. Используйте его для обслуживания контента вашего сайта. Также теперь вы можете установить более сложный программный стек для поддержки сайта.
Конечно, сначала может быть сложно запомнить все команды и рекомендации по управлению сервером Nginx. Это руководство предназначено для тех, кто работает с Nginx. Оно охватывает некоторые основные команды управления сервисами, а также советы по диагностике и решению некоторых распространенных проблем.
Каждый раздел может использоваться независимо от других, поэтому вы можете пропустить разделы, которые вам не нужны. Все условные значения в командах выделены красным; вместо этих значений вы можете подставить свои данные.
Каждый раздел предлагает ссылки на другие руководства, с которыми можно проконсультироваться.
Примечание: Предполагается, что вы работаете с версией Nginx, установленной из репозитория по умолчанию в Debian-подобном дистрибутиве. Некоторые из команд и директив, описанных в этом руководстве, отсутствуют в других дистрибутивах или в версиях Nginx, установленных из других источников.
Установка Nginx
Обновите индекс пакетов, а затем установите Nginx:
sudo apt-get update
sudo apt-get install nginx
Проверка состояния Nginx
Чтобы проверить состояние веб-сервера на текущей машине, введите:
sudo systemctl status nginx
Автозагрузка Nginx
По умолчанию сервис Nginx запускается автоматически. Если вы хотите изменить это поведение, введите:
sudo systemctl disable nginx
Чтобы снова добавить Nginx в автозагрузку, введите:
sudo systemctl enable nginx
Управление сервисом Nginx
Чтобы остановить сервер Nginx, введите следующую команду:
sudo systemctl stop nginx
Чтобы запустить сервер Nginx, введите:
sudo systemctl start nginx
Чтобы остановить сервис и запустить его снова, введите:
sudo systemctl restart nginx
Если вы изменили конфигурацию, вы можете перезагрузить Nginx в текущей сессии. Введите следующую команду:
sudo systemctl reload nginx
Создание корневого каталога для статического контента
При создании сайтов на Nginx разработчики часто используют виртуальные хосты (или блоки server) – это хосты, которые обслуживают отдельные сайты или домены. Для этого нужно создать document root, каталог верхнего уровня, который Nginx проверяет при обслуживании контента.
Команды в приведенном ниже блоке создадут новый корневой каталог, передадут права на него пользователю sudo и изменят права доступа к каждому подкаталогу в подкаталога в /var/www/.
В данном случае корневой каталог предлагает глобальные права на чтение и исполнение. Чтобы выбрать другие права доступа, замените 775 и укажите требуемые права.
Помните, что права доступа должны меняться в соответствии с ситуацией.
Создание корневого каталога для динамических файлов
Если ваш сайт использует динамические модули типа PHP-FPM, вам может понадобиться передать права на некоторые файлы группе www-data. Если группе нужно право на запись в каталоге, передайте группе права собственности на каталог.
Включение и отключение конфигурационных файлов
Чтобы включить виртуальный хост, нужно создать симлинк из каталога sites-available в каталог sites-enabled, который Nginx читает во время запуска.
Для этого введите комнаду:
После этого нужно перезагрузить Nginx, чтобы настройки обновились.
Устранение неполадок с хэш-таблицей
Nginx использует хэш-таблицы, чтобы быстро обрабатывать статические данные (имена серверов, MIME-типы). Если вы добавили несколько имен серверов, есть вероятность, что заданного размера хэша имени сервера будет не хватать, и при внесении изменений вы увидите ошибку server_names_hash_bucket_size. Ее можно устранить, отредактировав одно значение в файле /etc/nginx/nginx.conf.
Откройте этот файл:
sudo nano /etc/nginx/nginx.conf
Это увеличит размер хэш-таблиц имен серверов Nginx и позволит сервису обрабатывать все имена серверов, которые вы добавили. Сохраните и закройте файл, а затем перезапустите Nginx, чтобы обновить настройки.
Тестирование конфигурации
Каждый раз, когда вы вносите изменения в конфигурационные файлы Nginx, обязательно выполните следующую команду, чтобы проверить наличие синтаксических ошибок:
Если в конфигурации есть ошибки, вывод команды укажет, где именно они обнаружены. Если же в конфигурационных файлах нет синтаксических ошибок, вы увидите примерно такой вывод:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
Если ошибок нет, вы можете перезагрузить сервис:
sudo systemctl restart nginx
Важные файлы и каталоги Nginx
Контент
Конфигурация сервера
- /etc/nginx/: конфигурационный каталог Nginx (здесь хранятся все конфигурационные файлы веб-сервера).
- /etc/nginx/nginx.conf: главный конфигурационный файл веб-сервера, в котором находятся все глобальные параметры.
- /etc/nginx/sites-available/default: виртуальный хост Nginx по умолчанию. Другие виртуальные хосты также должны храниться в каталоге sites-available (но они не будут работать без симлинка в sites-enabled).
- /etc/nginx/sites-enabled/: здесь хранятся файлы включенных виртуальных хостов. При запуске или перезагрузке Nginx читает конфигурационные файлы и ссылки в этом каталоге, чтобы собрать полную конфигурацию.
- /var/log/nginx/access.log: это лог, который регистрирует все запросы Nginx (если в конфигурации веб-сервера не сказано другого).
- /var/log/nginx/error.log: это лог ошибок.
Чтобы получить доступ к логам systemd процесса Nginx, запустите эту команду:
sudo journalctl -u nginx
Заключение
Данный мануал перечислил общие процедуры по поддержке сервера Nginx. Чтобы узнать больше о работе с Nginx, ознакомьтесь со следующими руководствами:
Рано или поздно с проблемами и сбоями сталкивается каждый веб-сервер или сайт. Зная, где искать ошибки и по каким причинам они возникают, вы можете быстро устранить их и минимизировать потери трафика.
В этом руководстве речь пойдёт о самых распространенных ошибках, которые случаются на сайте.
Типичные ошибки
Подавляющее большинство проблем, с которыми вы столкнетесь при попытке запустить сайт, очень предсказуемы и случаются почти с каждым.
Прежде чем приступить к действиям, следует найти ответы на следующие вопросы:
- Установлен ли веб-сервер?
- Работает ли он?
- Нет ли ошибок в конфигурациях веб-сервера?
- Открыты ли порты (не блокирует ли их брандмауэр)?
- Правильно ли указаны настойки DNS?
- Правильно ли настроен каталог document root?
- Обслуживает ли веб-сервер правильные индексные файлы?
- Правильно ли установлены права доступа и структура файлов и каталогов?
- Ограничен ли доступ к файлам конфигурации?
- Если у вас есть база данных, работает ли она?
- Может ли сайт подключиться к базе данных?
- Поддерживает ли веб-сервер передачу динамического контента в обработчик сценариев?
Это лишь некоторые из самых распространенных проблем, с которыми сталкиваются администраторы во время сбоя сайта. Точную проблему, как правило, можно обнаружить в логах разных компонентов; также можно обратиться к страницам ошибок в браузере.
Проверка логов
Прежде чем приступить к устранению неполадок, проверьте логи веб-сервера и других связанных с ним компонентов. Обычно эти файлы хранятся в каталоге /var/log.
К примеру, логи Apache на сервере Ubuntu обычно хранятся в каталоге /var/log/apache2. Просмотрите логи и найдите в них информацию об ошибках. Если вы используете БД, ознакомьтесь с ее логами.
Используйте поисковую систему, чтобы найти полезную информацию, которая может помочь найти решение проблемы.
Проверка веб-сервера
Для начала нужно убедиться, что веб-сервер установлен и может обслуживать сайт.
В некоторых ситуациях вы можете случайно деинсталлировать веб-сервер при выполнении других операций с пакетами.
Если вы работаете в системе Ubuntu или Debian и хотите установить веб-сервер Apache, вы можете ввести:
sudo apt-get update
sudo apt-get install apache2
В этих системах процесс Apache называется apache2.
Чтобы установить Nginx в Ubuntu или Debian, введите:
sudo apt-get update
sudo apt-get install nginx
Процесс Nginx называется nginx.
Чтобы установить Apache в CentOS или Fedora, введите:
Чтобы установить Nginx в CentOS или Fedora, введите:
Процесс Nginx называется nginx.
Состояние веб-сервера
Затем нужно убедиться, что веб-сервер запущен.
Есть много способов узнать, запущен ли он. Один из общих методов – команда netstat.
Она покажет вам все процессы, которые используют порты сервера. Затем можно использовать grep, чтобы найти имя требуемого процесса.
sudo netstat -plunt | grep apache2
tcp6 0 0 . 80 . * LISTEN 2000/apache2
Примечание: Вместо apache2 укажите имя искомого процесса веб-сервера.
Если вы видите такую строку, как в примере выше, это значит, что процесс запущен и работает. Если вы не получили никакого вывода, значит, вы запросили неправильный процесс или ваш веб-сервер не запущен.
В таком случае нужно запустить его.
Чтобы запустить Apache2 в Ubuntu, введите:
sudo service apache2 start
В CentOS для этого нужно ввести:
Состояние веб-сервера можно снова проверить с помощью netstat.
Ошибки в конфигурациях
Если веб-сервер установлен и запущен, но всё равно не обслуживает сайт, возможно, в конфигурационном файле допущены какие-то ошибки. Веб-серверы Apache и Nginx требуют строго придерживаться синтаксиса директив.
Конфигурационные файлы этих сервисов обычно находятся в подкаталогах каталога /etc/.
Таким образом, основной конфигурационный каталог Apache в Ubuntu можно найти так:
Конфигурационный каталог Apache в CentOS:
Конфигурация веб-сервера хранится в различных файлов. Если сервис не запускается, она обычно указывает конфигурационный файл и строку, в которой допущена ошибка. Проверьте этот файл.
Каждый веб-сервер также предоставляет возможность проверить синтаксис конфигурации с помощью специальных команд.
В Apache для проверки синтаксиса используется apache2ctl или apachectl.
apache2ctl configtest
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message
Syntax OK
Команда предоставляет информацию о настройках и сообщает об ошибках, если таковые есть (в данном случае ошибок не обнаружено).
Чтобы проверить синтаксис Nginx, нужно ввести:
sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
sudo nginx -t
nginx: [emerg] invalid number of arguments in "tcp_nopush" directive in /etc/nginx/nginx.conf:18
nginx: configuration file /etc/nginx/nginx.conf test failed
Nginx обнаружит ряд недействительных аргументов, поскольку не сможет найти точку с запятой в конце выражения. Если точки с запятой нет в конце строки, веб-сервер интерпретирует следующую строку как дополнительные аргументы предыдущей.
Проверка портов
Обычно веб-сервер использует порт 80 для обычного трафика и 443 для трафика TLS/SSL. Если эти порты заблокированы, вы не сможете получить доступ к сайту.
Проверить порты можно с помощью локальной машины и команды netcat.
Укажите IP-адрес сервера и требуемый порт:
sudo nc -z 111.111.111.111 80
Эта команда проверит, открыт ли порт 80 на сервере по адресу 111.111.111.111. Если он заблокирован, команда будет безуспешно пытаться создать соединение. Вы можете остановить этот процесс, нажав Ctrl-C в окне терминала.
Если порты недоступны, проверьте конфигурацию брандмауэра. Возможно, вам нужно открыть порт 80 или 443.
Проверка настроек DNS
Если вы можете получить доступ к сайту по IP-адресу, а по доменному имени – нет, проверьте параметры DNS.
Чтобы пользователи могли попасть на сайт по домену, нужно создать запись А или АААА, которые будут указывать на IP-адрес сервера.
Чтобы проверить запись А, введите:
Строка, которая появится на экране, должна содержать IP-адрес сервера. Чтобы проверить запись АААА (для IPv6), введите:
Имейте в виду, изменение настроек DNS занимает довольно много времени. В течение некоторого времени после внесения изменений вы можете получить непоследовательные результаты запросов, поскольку настройки DNS еще не обновлены.
Убедитесь, что домен указан в конфигурационных файлах других сервисов.
Если записи DNS настроены правильно, проверьте файлы виртуальных хостов Apache и Nginx и убедитесь, что они содержат правильный домен сайта.
В Apache найдите этот раздел:
В Nginx домен указывается в этом блоке:
Настройки корневого каталога
Также нужно убедиться, что веб-сервер знает, где искать файлы сайта.
Каждый виртуальный хост Apache и Nginx определяет корневой каталог сайта. если Он указан неправильно, сервер вернёт ошибку, потому что не найдет запрашиваемый контент.
В Apache каталог document root настраивается с помощью директивы DocumentRoot:
Согласно этим настройкам веб-сервер будет искать файлы в каталоге /var/www/html. Если в этом каталоге на самом деле нет файлов сайта, укажите в настройках правильный каталог.
В Nginx корневой каталог определяет директива root.
Согласно этому файлу Nginx будет искать данные для этого домена в каталоге /usr/share/nginx/html.
Проверка индексных файлов
Если корневой каталог указан правильно, но индексные страницы неверно отображаются при переходе на сайт, возможно, они настроены неправильно.
Когда пользователь запрашивает каталог, сервер выдает ему индексный файл (index.html или index.php, в зависимости от конфигураций).
В виртуальном хосте Apache можно найти строку, которая настраивает порядок отображения индексных файлов.
<Directory /var/www/html>
DirectoryIndex index.html index.php
</Directory>
Когда запрашивается каталог, Apache сначала будет искать файл index.html; если он не сможет обслужить этот файл, он найдёт и обслужит index.php.
Вы можете настроить порядок обслуживания индексных файлов. Для этого можно отредактировать файл mods-enabled/dir.conf, в котором хранятся настройки сервера по умолчанию. Если сервер не обслуживает индексные файлы, убедитесь, что такие файлы есть в корневом каталоге сайта.
В Nginx индексными файлами управляет директива index:
Проверка прав собственности и доступа
Чтобы веб-сервер мог правильно обслуживать файлы, он должен иметь возможность читать их и иметь доступ к каталогам, в которых они хранятся.
Каталоги, в которых хранится контент сайта, должны предоставлять веб-серверу права на чтение и выполнение. Имя пользователя и группы, которые используются для запуска веб-сервера, зависят от дистрибутива.
В Ubuntu и Debian серверы Apache и Nginx работают с помощью пользователя www-data, который входит в группу www-data.
В CentOS и Fedora веб-сервер Apache работает как пользователь apache, который входит в группуapache; а Nginx использует учетную запись nginx, которая входит в группу nginx.
Вы можете посмотреть каталоги и файлы, в которых хранится контент сайта:
ls -l /path/to/web/root
Пользователь и группа веб-сервера должны иметь право на чтение и запуск каталогов и право на чтение файлов с контентом сайта. Чтобы загрузить, записать или изменить контент, веб-сервер также должен иметь права на запись в файлах и каталогах.
Примечание: Настраивать права на запись в каталогах нужно с большой осторожностью, потому что это может представлять угрозу безопасности системы.
Чтобы передать права собственности на файл, введите:
sudo chown user_owner:group_owner /path/to/file
Точно так же можно передать права на каталог, нужно только добавить флаг –R.
sudo chown -R user_owner:group_owner /path/to/file
Проверка ограничений доступа
Возможно, некоторые конфигурационные файлы блокирую доступ к файлам сайта, которые нужно обслужить.
В Apache доступ может блокировать виртуальный хост или файл .htaccess.
Эти файлы позволяют ограничить доступ несколькими способами. В Apache 2.4 доступ к каталогам ограничивается так:
<Directory /usr/share>
AllowOverride None
Require all denied
</Directory>
Эта строка блокирует доступ к содержимому этого каталога. В Apache 2.2 доступ блокируется так:
<Directory /usr/share>
AllowOverride None
Order deny,allow
Deny from all
</Directory>
Если вы найдете в конфигурационном файле такую директиву для каталога, в котором хранится контент сайта, вы не сможете открыть сайт.
В Nginx ограничения доступа настраиваются с помощью директивы deny и хранятся в виртуальных хостах или главных конфигурационных файлах:
location /usr/share deny all;
>
Проверка базы данных
Если сайт использует СУБД (например, MySQL, PostreSQL или MongoDB), убедитесь, что она запущена.
Для этого используется netstat. Команда grep поможет быстро найти в выводе процесс БД.
sudo netstat -plunt | grep mysql
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 3356/mysqld
Как видите, в данном случае сервис работает.
Затем нужно проверить, может ли сайт подключиться к БД. Для этого нужно убедиться, что сайт читает файлы, в которых указана информация о базе данных.
Например, параметры подключения к базе данных сайта WordPress хранятся в файле wp-config.php. Убедитесь, что DB_NAME, DB_USER и DB_PASSWORD указаны правильно.
Чтобы проверить информацию, указанную в файле, попробуйте подключиться к БД вручную:
mysql -u DB_USER_value -pDB_PASSWORD_value DB_NAME_value
Передача динамического контента
Если сайт использует БД, он почти наверняка использует язык программирования (например, PHP) для обработки запросов динамического контента, извлечения информации из базы данных и визуализации результатов.
Если это так, убедитесь, что веб-сервер может передавать запросы процессору.
В Apache достаточно убедиться, что модуль mod_php5 установлен и включен. В системах Ubuntu и Debian для этого введите:
sudo apt-get update
sudo apt-get install php5 libapache2-mod-php5
sudo a2enmod php5
В CentOS/Fedora это такие команды:
В Nginx проверить это немного сложнее. У Nginx нет модуля PHP, который можно включить, поэтому нужно убедиться, что php-fpm установлен и включен в конфигурациях веб-сервера.
На сервере Ubuntu или Debian убедиться, что все компоненты установлены, можно с помощью команды:
sudo apt-get update
sudo apt-get install php5-fpm php5-mysql
В CentOS и Fedora используйте:
sudo yum install php-fpm php-mysql
Поскольку PHP-процессор не входит в Nginx, он должен передавать файлы в PHP. Больше об этом можно узнать в руководстве Установка LEMP stack на Ubuntu 14.04.
Дальнейшие действия
Если ничего из вышеперечисленного не помогло, снова проверьте логи.
Надеемся, эти советы по устранению неполадок помогут вам выявить и устранить проблемы и ошибки, которые обычно возникают при запуске сайта.
В данной статье рассматривается установка и настройка связки Nginx и PHP -FPM на локальной ЭВМ, если требуется работа на выделенном сервере, то следует обратится к более серьезным инструкциям или/и непосредственной помощи специалистов Данная статья написана любителем, никто из профессионалов её не проверял, она может содержать ошибки и вредные советы и потому нацелена на тех, кто хочет поигратьсяСервер «Nginx» поставляется в одноименном пакете «nginx» и его установка производится, например, командой в терминале
Установку же «PHP-FPM» можно произвести, например, командой
Наряду с уязвимостями присущими ПО сервера, присутствуют также те, что обусловлены неосторожностью администратора сервера. Для их устранения следует соблюдать меры предосторожности:
Следует следить за логами работы сервера, это позволяет выявить попытку взлома как можно раньше и минимизировать угрозу дальнейшего ущерба. Необходимо обновлять ПО (в том числе «CMS» — системы управления содержимым сайтов), но не обязательно тогда когда выходят новые версии (они тоже могут содержать новые уязвимости), а, прежде всего, тогда, когда обновление связано с устранением серьезной уязвимости. Обязательное наличие файлов для отката состояния сервера (в том числе, конфигурационных файлов). Осторожное и осмотрительное следование подобным инструкциям (см. Don’t trust the tutorials: check your configuration!)Настройка состоит из двух этапов — настройки «Nginx» и «PHP-FPM». Для начала необходимо остановить процессы (демоны) «Nginx» и «PHP-FPM», например, командами
Настройка PHP-FPM
Прежде всего, следует открыть файл «/etc/php5/fpm/php.ini» для редактирования, например, командой
после чего, найти строчку содержащую «cgi.fix_pathinfo», которая по-умолчанию выглядит так (закомментирована)
и привести её к виду
Это призвано устранить опасность неправильно трактования (и возникающей уязвимости) запросов вида «/image.jpg/foo.php» (см. Don’t trust the tutorials: check your configuration!, Nginx 0day exploit for nginx + fastcgi PHP).
Если планируется загрузка больших файлов (важно для ownCloud версий < 8, в новой версии 8 и выше имеется отдельный файл для этих настроек), то можно увеличить максимальный объем загружаемых данных, например, до 200 МБ
Затем сохранить изменения в файле.
найти строчку с параметров «security.limit_extensions» и привести её к виду
Эта настройка ограничит выполнение файлов по расширению имени. В этом же файле найти строчку с параметром «listen» и привести её к виду
Это определит файл для связи «Nginx» с «PHP-FPM» (сокет). В целях безопасности запрещаем какой-попало программе писать в сокет (см. Обновление PHP 5.5.12 с устранением уязвимости в PHP-FPM ) путём указания прав доступа к сокету. Находим строчки с описанием параметров «listen.owner», «listen.group» и «listen.mode» (по-умолчанию они закомментированы) и приводим их к виду
Следует сохранить изменения в файле и перезапустить «PHP-FPM», например, командой
Можно убедится в том, что права доступа к сокету установлены верно:
Права доступа должны быть «srw-rw—-», владелец «www-data» (группа «www-data»), например,
Настройка Nginx
и откроем его для редактирования
Некоторые запросы «Nginx» будет перенаправлять к «PHP-FPM», который в данном случае называется сервером выгрузки данных (upstream). Укажем как следует это делать. Создадим файл конфигурации с описанием серверов выгрузки данных
и откроем его для редактирования
и добавим в него строчки
где «php-fpm» – название для сервера выгрузки данных, для удобства.
для загрузки созданого выше конфигурационного файла. Как можно видеть – допускается указание относительного пути к файлу.
иначе, можно опустить эти строчки.
Начинаем описывать конфигурацию сайта
Корневая директория сайта работающего на данном сервере
Имя сервера – обычно доменное имя Вашего сервера
Шифрование
Необходимо наличие сертификата «*.crt» или «*.pem» и приватного секретного ключа «*.key» (см. Сертификаты). Самоподписанный сертификат можно сгенерировать командой в терминале (см. man openssl, man req)
затем сформировать файл запроса на подпись (при этом прийдётся вводить те же данные что и для генерации самоподписанного сертификата, но это не важно, т.к. сервис «StartSSL» проигнорирует все кроме публичного ключа)
открыть полученный файл текстовым редактором
и скопировать его содержимое в текстовое поле на сайте «StartSSL» для запроса сертификата (см. ссылки на подробные инструкции выше). Файл *.csr больше не нужен. Затем загружаем подписанный сертификат (например, файл называется signed.crt) и объединяем его с сертификатом того кто этот сертификат подписал
Файл «signed.crt» можно удалить.
Копируем секретный ключ в системную папку и выставляем права доступа
И в соседнюю папку сам сертификат
Для пущей надежности можно сгенерировать ключ Диффи-Хеллмана (тоже секретный файл который очень долго генерируется)
Продолжаем редактировать конфигурационные файлы.
Для удобства описываем настройки шифрования во внешнем файле «/etc/nginx/common/ssl»
Редактируем файл «/etc/nginx/common/ssl»
На этом настройки «SSL» в «Nginx» завершены, сохраняем и закрываем файл. После завершения описания конфигурации (см. ниже) можно будет проверить надежность сервисом «SSLLabs»
Прочие настройки
Указание максимального размера запроса – необходимо если сервер будет использоваться для загрузки больших файлов (например, для построения небольшого облачного хранилища на основе «ownCloud», эта строчка по сути делает то же что и указанные выше при настройке «PHP-FPM», только теперь для «Nginx»)
Безопасность
Опишем настройки безопасности в отдельном файле
Сохраним и закроем файл, а затем подключим его строкой
Сжатие
Для экономии трафика лучше включить сжатие (иногда со влючённым сжатием могут возникать проблемы, например, у «ownCloud», см. ниже). Опишем настройки сжатия в отдельном файле
Следует сохранить, закрыть и затем подключить этот файл срочкой
Директории сайта
Далее указание директорий сайта и правил работы с ними с использованием директив «location». Данная директива может обрабатывать регулярные выражения «Perl» (см. Регулярные выражения (шаблоны))
Важно учитывать порядок проверки директив «location» (см. location) Блокировать доступ к файлам и подпапкам обычно следует посредством регулярных выраженийК примеру, если хочется построить сайт на основе «WordPress», то можно описать корневую директорию так
Соответственно сам сайт должен размещаться в каталоге «/var/www/wordpress/»
Директории можно описывать по одной в этом же файле, но это не удобно и не наглядно. А можно указать строчку
которая укажет «Nginx», что нужно подключить все файлы в директории «/etc/common/locations/» которые соответствуют шаблону «*.inc», таким образом, если один из файлов нужно будет временно отключить, то его можно просто переименовать убрав расширение в имени. Создадим директорию где будут хранится эти файлы
Некая директория «/var/www/restricted» доступная только авторизованным пользователям сервера. Создадим для неё файл конфигурации «/etc/nginx/common/locations/restricted.inc»
» указывает, что при совпадении здесь директивы «location» ниже проверяться не будут.
Этот конфигурационный файл подключится автоматически, за счёт шаблона (см. выше).
Wordpress
Натройки «Wordpress», который, в данном примере, находится в папке «/var/www/wordpress» будут описаны в файле «/etc/nginx/common/locations/wordpress.inc»
Указываем виртуальную директорию (используется для удобства и читабельности) в которую будут перенаправляться запросы при необходимости
Аналогично примеру выше предотвращаем обработку остальных директив «location»
Сохраняем и закрываем этот файл. Опять же, он будет подключён автоматически.
ownCloud
Для наиболее полной информации следует обратится к официальному руководству «OwnCloud» (см. Nginx Configuration). К примеру, «ownCloud» находится в папке «/var/www/owncloud».
Создадим файл настроек для «ownCloud» и отредактируем его
Многое аналогично примеру для «Wordpress»
Начиная с версии «ownCloud» 8 появился отдельный файл для переопределения некоторых настроек «PHP-FPM» взамен указанных в «/etc/php5/fpm/php.ini». Открыть его можно командой
и в нем найти строчки
и поменять значения на требуемые.
Базовые ограничения
Выше была написана строчка для подключение файла «/etc/nginx/common/deny»
рассмотрим его содержание. В нём идет запрет доступа к некоторым стандартным файлам. Создадим этот файл
Следует быть бдительным, неверно указанный шаблоны для запрета доступа (не только здесь но и в примерах выше) могут сильно навредить. Например, клиент ownCloud может начать удалять файлы которые не сможет загрузить на сервер из-за неправильного запрета где-то в конфигурационном файлеСледует переписать все файлы «.htaccess» в директивы «Nginx». Найти эти файлы среди файлов сайта можно, например, командой
Вызов PHP-FPM
В примерах выше использовался файл «/etc/nginx/common/php-fpm» — в нём идет перенаправление обработки php-скриптов внутреннему серверу «PHP-FPM»
Создаём этот файл
Кеширование
Выше, в примерах, был упомянут файл «/etc/nginx/common/cache»
Сайт работает значительно лучше когда часть контента сохранена на стороне клиента с прошлого посещения сайта. Не все файлы можно кешировать. Поэтому описание кеширования производится в самом конце (т.е. эти настройки будут иметь наименьший приоритет и есть шанс что это не повлияет на правильную работу сайта). Создадим файл с параметрами для кеширования
Читайте также: