题 site-available与nginx的conf.d目录有什么不同的用法


我有一些使用linux的经验,但没有使用nginx。我的任务是研究应用程序服务器的负载平衡选项。

我用apt-get来安装nginx,一切似乎都很好。

我有一些问题。

sites-available文件夹和conf.d文件夹之间有什么区别。在nginx的默认配置设置中,这两个文件夹都包含在内。教程使用两者。它们是什么,最佳实践是什么?

启用网站的文件夹用于什么?我该如何使用它?

默认配置是否引用了www-data用户?我必须创建该用户吗?如何为该用户提供运行nginx的最佳权限?


73
2017-07-31 14:20




在提问时尽量避免范围蔓延; www-data 是一个单独的主题。大多数操作系统定义一个具有较低权限的单独用户,该进程可以在以root身份绑定到端口80之后运行。它在配置文件中定义。从那里应用基本安全实践;不要让用户写入Web服务器不应该写入的任何内容,不要让其他用户写入文件,除非是故意的。 - Andrew B


答案:


sites- *文件夹由。管理 nginx_ensite 和 nginx_dissite。对于通过搜索找到它的Apache httpd用户,等价物是 a2ensite/a2dissite

sites-available 文件夹用于存储 所有 您的vhost配置,无论它们当前是否已启用。

sites-enabled 文件夹包含符号链接到sites-available文件夹中的文件。这允许您通过删除符号链接来有选择地禁用vhost。

conf.d 完成这项工作,但是当你需要禁用某些东西时,你必须从文件夹中移出一些东西,删除它或对其进行更改。 sites- *文件夹抽象使事情更有条理,并允许您使用单独的支持脚本来管理它们。

(除非你像我一样,并且是直接管理符号链接的许多debian管理员之一,不知道脚本......)


69
2017-07-31 15:01



我弄错了吗?不理解downvote。 - 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.

所以,回答最初的问题:没有内部差异,你可以用最好的方式使用它们,记住其他答案的建议。请不要忘记选择“正确”的答案。


28
2018-04-16 20:29



对, sites-enabled 已经有点发明了一些ditribution,作为一个烦人的中间体做模糊。从中获取nginx 官方消息来源:你将得到一个最新的产品,以及摆脱这种配置废话/地狱。 - 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



拥有专用用户来运行Web服务器也很重要,因为通过删除有效的shell记录来禁用此用户的登录功能。 - DukeLion
>'你应该让nginx作为非root用户运行' - 你能详细说明一下吗? - lfender6445
以非特权用户身份运行是一种遏制远程攻击可能造成的损害的方法。如果您正在运行Web服务器 root 并且存在某种远程攻击,攻击者立即拥有对系统的完全访问权限。当作为非特权用户运行时,管理访问只能与某种本地漏洞利用相结合。 - larsks


这是怎么回事?

你必须使用Debian或Ubuntu,因为 邪恶  sites-available / sites-enabled 逻辑不被使用 nginx的上游包装 从 http://nginx.org/packages/

在任何一种情况下,都是在标准的帮助下实现的配置约定 include 指令 /etc/nginx/nginx.conf

这是一个片段 /etc/nginx/nginx.conf 来自nginx.org的nginx官方上游软件包:

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~ 包含在活动配置中,根据使用的指令,甚至可能不会给您任何警告,并导致延长的调试会话。 (是的,它确实发生在我身上;它是在黑客马拉松期间,我完全不知道为什么我的conf不工作。)

因此,我确信这一点 sites-enabled 是纯粹的邪恶!


6
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
很明显,a)这不是讨论的适当媒介,也许更重要的是,b)在任何情况下它都可能毫无结果。让我们接收有差异的看法。 - BE77Y