Вопрос: Каковы различные способы использования доступных сайтов, а также каталог conf.d для nginx


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

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

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

В чем разница между папками, доступными для сайтов, и папкой conf.d. Обе эти папки были ВКЛЮЧЕНЫ в настройку конфигурации по умолчанию для nginx. В учебниках используются оба варианта. Для чего они нужны и что является лучшей практикой?

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

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


70
2017-07-31 14:20


Источник


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


Ответы:


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

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

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

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

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


66
2017-07-31 15:01



У меня что-то не так? Не понимаю нисходящего. - Andrew B
Мне любопытно, что это встроено в nginx? я установил вручную github.com/perusio/nginx_ensite - lfender6445
Важно отметить, что sites-available|sites-enabled является Debian-ism и не является чем-то, что делают nginx или Apache. Вероятно, это было довольно полезно в прошлом, но его утилита несколько ограничена в эпоху управления конфигурацией и контейнеров. - Michael Hampton♦


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

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

Единственная директива, используемая здесь, включают, поэтому нет внутренней разницы между, например, 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.

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


27
2018-04-16 20:29



Правильно, sites-enabled был несколько придуман каким-то образом, пушистым, как раздражающее промежуточное звено. Go grab nginx от официальный источник: вы получите обновленный продукт, а также избавитесь от этой конфигурации crap / hell. - Bernard Rosset
Это объясняет, почему в официальной документации Nginx нет ни одной ссылки этого соглашения о названии. Это третий проект! github.com/perusio/nginx_ensite - AxeEffect


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

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

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

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

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

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


25
2017-07-31 14:59



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


Что происходит?

Вы должны использовать 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 это чистое зло!


5
2017-08-27 20:08



В дополнение ко всему вышесказанному, по-видимому, очень часто создавать неправильные символические ссылки! 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
Понятно, что а) это не подходящая среда для этого обсуждения и, возможно, даже более важно, б) в любом случае это может оказаться бесплодным. Давайте согласимся не согласиться. - BE77Y