Какое использование сайтов доступно по сравнению с каталогом conf.d для nginx?

99

У меня есть некоторый опыт использования Linux, но ни один из них не использует nginx. Мне было поручено исследовать варианты балансировки нагрузки для сервера приложений.

Я использовал apt-get для установки nginx, и все выглядит нормально.

У меня есть пара вопросов.

В чем разница между папкой sites-available и папкой conf.d. Обе эти папки были включены в настройки конфигурации по умолчанию для nginx. Учебники используют оба. Для чего они и какова лучшая практика?

Для чего используется папка с поддержкой сайтов? Как мне это использовать?

Конфигурация по умолчанию ссылается на пользователя www-data? Должен ли я создать этого пользователя? Как дать этому пользователю оптимальные разрешения для запуска nginx?

Сет Спирман
источник
Старайтесь избегать ползучести при задании вопроса; www-dataэто отдельная тема. Большинство операционных систем определяют отдельного пользователя с более низкими разрешениями, который процесс может запускать после привязки к порту 80 от имени пользователя root. Это определено в файле конфигурации. Применяйте основные методы безопасности оттуда; не позволяйте пользователю писать что-либо, к чему веб-сервер не должен писать, не позволяйте другим пользователям писать в файлы, если это не сделано преднамеренно.
Андрей Б,

Ответы:

94

Папки сайтов - * управляются nginx_ensiteи nginx_dissite. Для пользователей Apache httpd, которые находят это с помощью поиска, эквивалентами является a2ensite/ a2dissite.

sites-availableПапка для хранения всех ваших конфигураций ВХост, идет ли они или нет в настоящее время включен.

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

conf.dвыполняет работу, но вы должны переместить что-то из папки, удалить ее или внести в нее изменения, когда вам нужно что-то отключить. Абстракция папок sites- * делает вещи немного более организованными и позволяет управлять ими с помощью отдельных сценариев поддержки.

(если вы не похожи на меня и одного из многих администраторов Debian, которые просто управляли символическими ссылками напрямую, не зная о сценариях ...)

Андрей Б
источник
12
Я что-то не так понял? Не понимая, понижающий голос.
Андрей B
1
Мне любопытно, это встроено в Nginx? я установил вручную github.com/perusio/nginx_ensite
lfender6445
18
Важно отметить, что sites-available|sites-enabledэто Debian-ism, а не nginx или Apache. Вероятно, это было довольно полезно в прошлом, но его полезность несколько ограничена в эпоху управления конфигурациями и контейнерами.
Майкл Хэмптон
Можете ли вы прокомментировать, как управление конфигурацией и контейнерами ограничивает полезность сайтов с доступными сайтами?
Картик Ви
1
@karthikvee суть в том, что в настоящее время серверы часто выглядят как эфемерные контейнеры, которые обслуживают только один веб-сайт / службу, поэтому их можно включить nginx.confбез потери читабельности. Это противоположно подходу, принятому несколько лет назад, когда серверы обычно хранили десятки веб-сайтов.
Адамчи
38

Я хотел бы добавить к предыдущим ответам, что наиболее важным является не то, как вы называете каталоги (хотя это очень полезное соглашение), а то, что вы фактически вставили nginx.conf. Пример конфигурации:

http {
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*.conf;
    include /etc/nginx/sites-enabled/my_own_conf;
...
}

Единственная директива, используемая здесь, это include , поэтому между eg conf.d/и sites-enabled/. Нет никакой внутренней разницы .

Из документации выше:

Syntax:     include file | mask;
Default:    —
Context:    any

Includes another file, or files matching the specified mask, 
into configuration. Included files should consist of 
syntactically correct directives and blocks.

Итак, чтобы ответить на исходный вопрос: нет внутренней разницы, и вы можете использовать их наилучшим образом, помня советы из других ответов. И, пожалуйста, не забудьте выбрать «правильный» ответ.

Ярослав Никитенко
источник
1
Правильно, sites-enabledэто было несколько придумано каким-то делением, суетящимся вокруг, как надоедливый посредник. Пойди, возьми nginx из официального источника : ты получишь обновленный продукт, а также избавишься от этой дерьмовой конфигурации.
Бернард Россет
2
Это объясняет, почему в официальной документации Nginx нет ни единой ссылки на это соглашение об именах. Это сторонний проект! github.com/perusio/nginx_ensite
AxeEffect
30

Как правило, sites-enabledпапка используется для определений виртуальных хостов, а conf.dиспользуется для конфигурации глобального сервера. Если вы поддерживаете несколько веб-сайтов, т. Е. Виртуальных хостов, то каждый из них получает свой собственный файл, поэтому вы можете очень легко включать и отключать его, перемещая файлы внутрь и наружу sites-enabled(или создавая и удаляя символические ссылки, что, вероятно, лучшая идея).

Используйте conf.dдля таких вещей, как загрузка модулей, файлы журналов и другие вещи, которые не относятся только к одному виртуальному хосту.

Конфигурация по умолчанию ссылается на пользователя www-data? Должен ли я создать этого пользователя?

Вы должны запустить nginx как пользователь без полномочий root. В некоторых случаях это называется www-data, но вы можете назвать его как угодно.

Как дать этому пользователю оптимальные разрешения для запуска nginx?

Я менее уверен в ответе на этот вопрос (сейчас я не запускаю nginx), но если это что-то похожее на Apache, ответ таков: www-dataпользователю нужны только разрешения на чтение любых статических файлов (и чтение + выполнение в каталогах). ) которые вы обслуживаете, или разрешения на чтение / выполнение таких вещей, как сценарии CGI, и никаких разрешений где-либо еще.

larsks
источник
1
наличие выделенного пользователя для запуска веб-сервера также важно из-за отключения возможности входа в систему для этого пользователя путем удаления допустимой записи оболочки.
DukeLion
> «У вас должен быть запущен nginx как пользователь без полномочий root» - не могли бы вы подробнее рассказать об этом?
lfender6445
1
Работа в качестве непривилегированного пользователя - это способ сдержать ущерб, который может быть вызван удаленным компромиссом. Если вы работаете с веб-сервером, rootи существует какой-либо удаленный компромисс, злоумышленник немедленно получает полный доступ к системе. При работе от имени непривилегированного пользователя административный доступ будет доступен только в сочетании с каким-либо локальным эксплойтом.
Жаворонки
14

В чем дело?

Вы должны использовать Debian или Ubuntu, так как зло sites-available / sites-enabledлогика не используется вышестоящей упаковкой nginx с http://nginx.org/packages/ .

В любом случае, оба реализуются как соглашение о конфигурации с помощью стандартной includeдирективы в /etc/nginx/nginx.conf.

Вот фрагмент /etc/nginx/nginx.confиз официального апстрим-пакета nginx от nginx.org:

http {
    …
    include /etc/nginx/conf.d/*.conf;
}

Вот фрагмент /etc/nginx/nginx.confиз Debian / Ubuntu :

http {
    …
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

Таким образом, с точки зрения NGINX, единственным отличием будет то, что файлы, которые будут получены, conf.dбудут обработаны быстрее, и, как таковые, если у вас есть конфигурации, которые незаметно конфликтуют друг с другом, то из них conf.dмогут иметь приоритет над конфигурациями в sites-enabled.


Лучшая практика conf.d.

Вы должны использовать /etc/nginx/conf.d, как это стандартное соглашение, и должно работать где угодно.

Если вам нужно отключить сайт, просто переименуйте имя файла, чтобы больше не иметь .confсуффикса, очень легко, просто и безошибочно:

sudo mv -i /etc/nginx/conf.d/default.conf{,.off}

Или наоборот, чтобы включить сайт:

sudo mv -i /etc/nginx/conf.d/example.com.conf{.disabled,}


Избегайте sites-availableи sites-enabledлюбой ценой.

Я не вижу абсолютно никакой причины использовать sites-available/ sites-enabled:

  • Некоторые люди упоминали nginx_ensiteи nginx_dissiteсценарии - имена этих сценариев даже хуже, чем остальная часть этого разгрома - но эти сценарии также нигде не найти - они отсутствуют в nginxпакете даже в Debian (и, вероятно, в Ubuntu) Кроме того, вам не нужен целый нестандартный сторонний скрипт для простого перемещения и / или связывания файлов между двумя каталогами ?!

  • И если вы не используете сценарии (что на самом деле является разумным выбором, как указано выше), то возникает вопрос, как вы управляете сайтами:

    • Вы создаете символические ссылки с sites-availableна sites-enabled?
    • Скопировать файлы?
    • Переместить файлы?
    • Редактировать файлы на месте в sites-enabled?

Вышеприведенное может показаться незначительными проблемами до тех пор, пока несколько человек не начнут управлять системой, или пока вы не примете быстрое решение, только чтобы забыть об этом спустя месяцы или годы…

Что приводит нас к:

  • Безопасно ли удалять файл из sites-enabled? Это мягкая ссылка? Жесткая ссылка? Или единственная копия конфигурации? Яркий пример конфигурации ада.

  • Какие сайты были отключены? (С conf.dпомощью поиска обращайтесь к файлам, не заканчивающимся на .conf- find /etc/nginx/conf.d -not -name "*.conf"или используйте grep -v.)

Не только все вышеперечисленное, но также обратите внимание на специальную includeдирективу, используемую Debian / Ubuntu /etc/nginx/sites-enabled/*- для суффикса имени файла не указано sites-enabled, в отличие от conf.d.

  • Это означает, что если однажды вы решите быстро отредактировать один или два файла внутри /etc/nginx/sites-enabled, и вы emacsсоздадите файл резервной копии, например default~, вдруг у вас будет и то, defaultи другое в default~качестве активной конфигурации, которая, в зависимости от используемых директив, может даже не дать Вы предупреждаете о каких-либо предупреждениях и вызываете длительный сеанс отладки. (Да, это случилось со мной; это было во время хакатона, и я был полностью озадачен, почему мой конф не работал.)

Таким образом, я убежден, что sites-enabledэто чистое зло!

CNST
источник
В дополнение ко всему вышесказанному, по-видимому, также очень часто создаются неправильные символические ссылки! stackoverflow.com/a/14107803/1122270 На всякий случай, если вы не думаете, sites-enabledбыло достаточно злым!
CNST
Или, иногда, может случиться так, что кто-то решит отредактировать файлы, в sites-enabledто время как другой решит отключить его, удалив его, возможно, думая, что это просто символическая ссылка, требующая последующий дамп памяти кучи nginx для восстановления файла conf: stackoverflow.com/q/45852224/1122270
CNST
Я должен не согласиться с утверждениями о sites-availableи sites-enabled; важно иметь возможность подготовить конфигурационные файлы вне «живого» каталога раскладки так, чтобы в случае перезагрузки или перезапуска nginx он не брал частичные конфигурационные файлы. Также может быть полезно сохранить конфигурационные файлы, которые больше не используются. Создание символических ссылок не является особенно сложной задачей, если у вас достаточно опыта, чтобы в первую очередь управлять nginx, IMO.
BE77Y
@ BE77Y у тебя более сложный подход. В программировании рекомендуется полностью удалять неиспользуемый код, а не просто отключать или комментировать его; Я не вижу причин, по которым DevOps должен отличаться - если конфигурация больше не нужна, удалите ее (она все еще должна существовать в вашей VCS). То же самое с частичными файлами conf - зачем вам их редактировать, а nginx перезагружается за вашей спиной? ( USR1который повторно открывает журналы, не перезагружает conf.) Я считаю, что ваши комментарии к "символическим ссылкам" на символическую ссылку неверно направлены - проблема заключается в согласованности, которая имеет мало общего с опытом.
CNST
2
Понятно, что а) это не подходящая среда для этой дискуссии и, возможно, что еще более важно, б) она может быть бесполезной в любом случае. Давайте согласимся не соглашаться.
BE77Y