Nginx (українська)
Ця сторінка потребує супровідника
nginx(вимовляється "енжин-екс" або "енжин-екс") - це вільний високопродуктивний HTTP-сервер з відкритим вихідним кодом, а також зворотний проксі та IMAP/POP3 проксі-сервер, написаний Ігорем Сисоєвим в 2005 року. Згідно з April 2015 Web Server Survey, nginx використовується на 14,48% доменів усього світу, в той час як Apache використовується приблизно на 38,39% доменів. nginx набув широкого поширення завдяки своїй стабільності, багатої функціональності, простому настроюванню та низькому споживанню ресурсів.
Для встановлення Ruby on Rails з nginx дивіться розділ Ruby on Rails # The Perfect Rails Setup.
Якщо для забезпечення додаткової безпеки ви хочете встановити nginx в chroot-оточенні, дивіться розділ #Установка в chroot.
Перші кроки з налаштування та використання nginx описані у посібнику Beginner's Guide. Ви можете налаштувати сервер, редагуючи файли /etc/nginx/ ; головний файл налаштувань розташований у /etc/nginx/nginx.conf.
Більш детальну інформацію можна прочитати на сторінці Nginx Configuration Examples та в офіційній документації.
Наведені далі приклади покривають більшість типових потреб. Передбачається, що ви використовуєте стандартне розташування веб-документів ( /usr/share/nginx/html ). Якщо це не так, замініть шлях на свій.
Основні налаштування
Процеси та з'єднання
Ви повинні вибрати потрібне значення для worker_processes . Цей параметр визначає скільки одночасних з'єднань зможе приймати nginx і скільки процесорів він зможе використовувати при цьому. Як правило, це значення встановлюють рівною кількістю апаратних потоків у системі. Однак, починаючи з версій 1.3.8 та 1.2.5, як значенняworker_processes ви також можете задати auto, при цьому nginx спробує автоматично підібрати оптимальне значення (джерело).
Максимальна кількість одночасних з'єднань, які nginx зможе приймати, обчислюється як max_clients = worker_processes * worker_connections .
Запуск під іншим користувачем
За промовчанням nginx виконується від імені користувачаnobody. Щоб запустити його від імені іншого користувача, змініть рядок user на nginx.conf :
Тепер Nginx повинен працювати від вказаного імені користувачакористувачта групигрупа. Якщо використовується група, ім'я якої збігається з ім'ям користувача, її назву можна опустити.
Блоки server
За допомогою додавання блоків server у файл налаштувань можна обслуговувати відразу кілька доменів одночасно. Ці блоки працюють аналогічно "VirtualHosts" в Apache.
У цьому прикладі сервер приймає запити для двох доменів: domainname1.dom та domainname2.dom :
Перезапустіть службу nginx , щоб зміни набули чинності.
openssl надає підтримку TLS/SSL та встановлено за замовчуванням на встановлених Arch.
Створіть секретний ключ та самопідписаний сертифікат. Це підходить для більшості випадків, які не потребують CSR:
Якщо вам потрібно створити CSR, дотримуйтесь цих інструкцій зі створення ключа замість наведених вище:
Приклад nginx.conf, що використовує SSL:
Перезапустіть службу nginx , щоб зміни набули чинності.
FastCGI або просто FCGI — це протокол, який є інтерфейсом між веб-сервером та інтерактивними програмами. Це модифікований CGI (Common Gateway Interface), головна мета якого - знизити накладні витрати, пов'язані із взаємодією веб-серверата CGI програм, тим самим дозволяючи серверу обробляти більшу кількість запитів одночасно.
Технологія FastCGI вбудована в nginx для роботи з багатьма зовнішніми інструментами, наприклад Perl, PHP і Python.
Реалізація PHP
Як FastCGI-сервер для PHP рекомендується використовувати PHP-FPM.
Налаштування PHP
Опція open_basedir у /etc/php/php.ini повинна містити список усіх каталогів, з файлами PHP, які мають бути доступні серверу. Наприклад, для /usr/share/nginx/html/ та /usr/share/webapps/ :
Основним конфігураційним файлом PHP-FPM є /etc/php/php-fpm.conf. Увімкніть та запустіть systemd службу php-fpm .
Налаштуйте MySQL/MariaDB як описано в MariaDB.
Налаштування nginx
Додавання до основної конфігурації
Всередині кожного блоку server, який обслуговує веб-додаток PHP, повинен знаходитися блок location:
Якщо потрібно обробляти інші розширення поряд з PHP (наприклад.htmlта.htm):
Усі розширення, що обробляються в php-fpm, повинні бути явно додані в /etc/php/php-fpm.conf :
Ви також можете використовувати спільний TCP-сокет:
Однак доменні сокети Unix повинні працювати швидше.
Приклад, наведений нижче, є копією робочої конфігурації. Зауважте, що в цьому прикладі шлях до root визначений безпосередньо в server , а не всередині location (як це зроблено в стандартній конфігурації).
Управління кількома блоками (опціонально)
Якщо ви додаєте однотипну конфігурацію для PHP відразу в безліч блоків server , може бути зручніше використовувати зовнішній файл:
Тепер увімкніть файл php.conf у кожен із блоків server :
Перевірка конфігурації
Перезапустіть служби php-fpm таnginx після зміни налаштувань, щоб зміни набули чинності.
Щоб перевірити роботу FastCGI, створіть новий файл.phpвсередині каталогу веб-документів, що містить:
При відкритті файлу в браузері має з'явитися інформаційна сторінка з поточними параметрами PHP.
Дивіться #Усунення проблем, якщо нова конфігурація не працює.
Реалізація CGI
Ця реалізація потрібна для CGI-додатків.
Встановіть fcgiwrap. Файл налаштувань знаходиться у /usr/lib/systemd/system/fcgiwrap.socket . Увімкніть та запустіть fcgiwrap.socket .
Декілька робочих потоків
Якщо ви хочете породити кілька робочих потоків, вам рекомендується використовувати multiwatch AUR , який вміє відстежувати підпроцеси, що впали, і перезапускати їх. Вам потрібно використовувати spawn-fcgi , щоб створити доменний сокет Unix, так як multiwatch не може обробляти сокети, створені systemd, однак, сама по собі не викликає жодних проблем, якщо викликається безпосередньо з юніт-файлу.
Скопіюйте юніт-файл з /usr/lib/systemd/system/fcgiwrap.service в /etc/systemd/system/fcgiwrap.service (і юніт fcgiwrap.socket , якщо він є), і відредагуйте рядок ExecStart відповідно до ваших потреб. У прикладі показаний юніт файл, який використовує multiwatch AUR. Переконайтеся, що fcgiwrap.socket не включений і не запущений, тому що він конфліктуватиме з цим юнітом:
Виберіть відповідний -f 10 , щоб змінити кількість підпроцесів, що породжуються.
Налаштування nginx
Всередині кожного блоку server CGI-програми повинен знаходитись вкладений блок location :
Стандартним сокетом для fcgiwrap є /run/fcgiwrap.sock.
Установка в chroot
Встановлення nginx у chroot додає додатковий рівеньбезпеки. Для максимальної безпеки chroot повинен включати лише файли, необхідні для запуску сервера nginx, при цьому всі файли повинні мати максимально обмежені права доступу. Наприклад, якомога більше файлів має належати користувачеві root, а таким каталогам, як /usr/bin, має бути встановлена заборона на читання та запис.
Arch поставляється з користувачем http та групою за промовчанням, від імені яких запускається сервер. Змінений кореневий каталог перебуватиме в /srv/http.
Створення необхідних пристроїв
Для nginx потрібні /dev/null , /dev/random та /dev/urandom . Щоб встановити їх у chroot, ми створимо каталог /dev і додамо пристрої за допомогоюmknod. Уникайте монтування всіх пристроїв у /dev : тоді, навіть якщо chroot буде скомпрометований, атакуючий повинен буде вибратися з chroot-оточення щоб дістатися важливих пристроїв, наприклад /dev/sda1 .
Створення необхідних каталогів
p align="justify"> Для роботи nginx вимагає певний набір файлів. Перед тим, як їх копіювати, створіть відповідні каталоги. Передбачається, що ваш кореневий каталог веб-документів nginx знаходиться у /srv/http/www.
Потім змонтуйте $JAIL/tmp і $JAIL/run як tmpfs. Розмір повинен бути обмежений, щоб бути впевненим, що атакуючий не зможе зайняти всю доступну RAM.
Для того, щоб монтування виконувалося автоматично при завантаженні системи, додайте наступні записи /etc/fstab :
Заповнення chroot
Спочатку скопіюйте прості файли.
Тепер скопіюйте необхідні бібліотеки. Використовуйтеldd, щоб відобразити їх та скопіюйте всі файли у правильне місце. Копіювання краще, ніж створення жорстких посилань, тому що навіть якщо атакуючий отримає права запису вфайли, вони не зможуть знищити або змінити системні файли поза chroot-оточенням.
Для файлів, що знаходяться в /usr/lib, ви можете скористатися наступною командою:
Копіюйте інші необхідні бібліотеки та системні файли.
Створіть файли користувачів та груп у chroot-оточенні. Таким чином, у chroot-оточенні будуть доступні тільки зазначені користувачі, і жодна інформація про користувачів з основної системи не буде доступна атакуючому, що отримає доступ у chroot-оточення.
Зрештою, зробіть права доступу максимально обмеженими. Якнайбільше має належати суперкористувачу і бути закритим для запису.
Якщо ваш сервер прийматиме вхідні з'єднання на 80 портах (або будь-якому іншому порту в діапазоні [1-1023]), дайте виконавцю chroot права на з'єднання з цими портами без необхідності прав суперкористувача.
Відредагуйте nginx.service для запуску chroot
Перед редагуванням юніт-файлу nginx.service непогано скопіюватиме його в /etc/systemd/system/ , тому що там юніт файли мають пріоритет над тими, що в /usr/lib/systemd/system/ . Це означає, що оновлення nginx не перезапише ваш власний файл.service.
Юніт systemd має бути налаштований так, щоб запускати nginx у chroot від імені користувача http і зберігати pid-файл у chroot.
Тепер ви можете спокійно видалити встановлений поза chroot nginx.
Вирішення проблем
Валідація конфігурації
При доступі з локального IP перенаправляється на localhost
За промовчанням nginx перенаправляє будь-які запити на вказане в опції server_name ім'я.
Помилка: Сторінка, яку ви шукаєте, тимчасово недоступна. Будь ласка, спробуйте пізніше. (502 Bad Gateway)
Це через те, що сервер FastCGIне запущений або сокет, що використовується, має неправильні права доступу.
Спробуйте цю відповідь, щоб виправити 502 помилку.
В Archlinux файлом налаштування, згаданим за посиланням вище, є /etc/php/php-fpm.conf .
За певних обставин fcgiwrap.socket може не запуститися правильно і створити марний сокет юнікс домену /run/fcgiwrap.sock .
Спробуйте зупинити службу fcgiwrap.socket і видалити файл доменного юнікса сокета за промовчанням.
Потім запустіть fcgiwrap.service замість нього. Перевірте статус fcgiwrap.service та нового доменного юнікса сокету /run/fcgiwrap.sock :
Якщо це спрацювало, вимкніть fcgiwrap.socket та увімкніть fcgiwrap.service .
Помилка: No input file specified
1. Швидше за все, у вас не встановлена змінна SCRIPT_FILENAME , що містить повний шлях до ваших скриптів. Якщо конфігурація nginx ( fastcgi_param SCRIPT_FILENAME ) правильна, то ця помилка означає, що php не зміг завантажити скрипт. Часто це просто виявляється помилкою прав доступу і ви можете запустити php-cgi з правами root:
або вам слід створити групу та користувача для запуску php-cgi:
2. Іншою причиною може бути те, що заданий неправильний аргумент root у секції location
\.php$ в nginx.conf . Переконайтеся, що root вказує на ту ж директорію, що і в location/на тому самому сервері. Або ви можете просто встановити абсолютний шлях до кореневого каталогу, не визначаючи його в будь-яких location секціях.
3. Переконайтеся, що змінна open_basedir у /etc/php/php.ini також містить шлях, який відповідає аргументу root у nginx.conf .
4. Також зверніть увагу, що не тільки php-скрипти повинні мати права на читання, але також і вся структура каталогів повинна мати правовиконання, щоб користувач PHP міг дістатися цього каталогу.
Помилка: "File not found" у браузері або "Primary script unknown" у лог-файлі
Переконайтеся, що ви визначили root та index у ваших директивах server або location :
Також переконайтеся, що файл, що запитується, існує на сервері.
Помилка: chroot: '/usr/sbin/nginx'
Якщо у вас виникає ця помилка при запуску демонаnginxу chroot, швидше за все, це відбувається через відсутні 64-бітові бібліотеки в ізольованому оточенні.
Якщо ваш chroot запущено в /srv/http , потрібно додати необхідні 64-бітові бібліотеки.
Спочатку створіть каталоги:
Потім скопіюйте необхідні 64-бітові бібліотеки, перелічені командою ldd /usr/sbin/nginx у /srv/http/usr/lib64 .
При запуску від root, на бібліотеки мають бути права читання та виконання для всіх користувачів, тому зміни не потрібні.
Альтернативний скрипт для systemd
На чистій systemd можна отримати переваги при використанні зв'язки chroot і systemd [1]. На основі заданих користувача та групи та pid:
абсолютним шляхом до файлу є /srv/http/etc/nginx/nginx.conf .3
Немає необхідності задавати розташування за промовчанням, nginx за замовчуванням завантажує -c /etc/nginx/nginx.conf , хоча це хороша ідея.
Також можна запускатитількиExecStart як chroot з параметром RootDirectoryStartOnly заданим як yes man systemd service або запустити його до точки монтування як ефективний або шлях systemd.
Увімкніть nginx.path і замініть WantedBy=default.target на WantedBy=nginx.path in /etc/systemd/system/nginx.service .
Посилання PIDFile у файлі юніту дозволяє systemd стежити за процесом(Необхідний абсолютний шлях). Якщо це небажано, ви можете змінити тип one-shoot за промовчанням та видалити посилання з файлу юніту.