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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы должны использовать Debian или Ubuntu, поскольку злые сайты доступны / сайты включены логика не используется восходящим пакетом 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 может иметь приоритет над данными на сайте s-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,}

Избегайте доступных сайтов и сайтов с поддержкой любой ценой.

Я не вижу абсолютно никаких причин для использования сайты доступны / сайты доступны :

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

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

  • Создаете ли вы символические ссылки с доступных сайтов на сайтов с поддержкой ?
  • Скопировать файлы?
  • Переместить файлы?
  • Отредактируйте файлы на месте в сайтах с поддержкой ?

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

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

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

• Какие сайты были отключены? (С помощью 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 ~ , включенные в качестве активной конфигурации, которая, в зависимости от используемых директив, может даже не выдавать никаких предупреждений и вызывать длительный сеанс отладки иметь место. (Да, это случилось со мной; это было во время хакатона, и я был совершенно озадачен, почему мой conf не работает.)

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