当我第一次开始进行 Web 编程并想要创建一个新项目时,我总是被教导在 中创建一个目录/var/www/
。然而,在我读过的很多教程中,人们倾向于在 中创建一个目录/home/username/
。
我不喜欢把它放进去的想法/home/username/
。
是否有正确的位置,如果没有,那么将其放在文件系统的某些区域有什么优点/缺点?
答案1
没有“最佳”目录。虽然人们可能会认为这个问题是主观的,或者文件的实际位置并不重要——后者他们说得对——但是关于在类 Unix 系统中将什么放在哪里的标准化建议。
这文件系统层次标准对此进行定义并为您提供以下内容:
/var
– 放置在正常运行期间发生变化的数据(如日志等)的位置/var/www
是 Apache 放置 Web 内容的默认目录,但它的使用根本没有标准化,只是您放置它的“通常”位置,因为人们不会经常更改默认设置。/srv
– 此目录应包含系统提供的数据。这通常是您想要的位置。FHS 解释道:指定此项的主要目的是让用户可以找到特定服务的数据文件的位置,并让需要单个树来存储只读数据、可写数据和脚本(例如 cgi 脚本)的服务可以合理放置。仅特定用户感兴趣的数据应放在该用户的主目录中。(…)
结构化数据的一种方法是通过协议
/srv
,例如ftp
,,,和rsync
www
cvs
因此,只需创建一个
/srv/www
目录并使用它即可。您可以为您可能想要用您的机器提供服务的每个虚拟主机创建子文件夹。/home
包含实际上应该只属于一个用户的文件。例如,Apache 允许用户目录,因此您可以通过 访问用户的 Web 文件,并且这些文件由用户主目录中的目录http://example.com/~username
提供。public_html
如果您使用多人共享的服务器,并且希望允许每个人托管自己的脚本,那么他们应该去这里。请记住,仅让目录可由其所属的用户写入。
本质上/srv/www
和/var/www
是您应该在其中为您可能想要托管的任何 Web 项目创建子目录的目录。然后,您可以在这些目录中定义不同的权限,以允许某些用户或用户组写入它们。如果您一次只有一个用户的项目,请使用/home
。
答案2
只要能够正确访问,你就可以把文件放在任何地方,但是如果有人稍后进来,混乱的文件系统就会令人头疼。
/srv
是最合乎逻辑的,如果你遵循文件系统层次结构标准,它就会放在这里。
如果你有多个域名,你可以执行/srv/domain1
/srv/domain2
等等,然后在里面创建子文件夹/ftp
/www
/tftp
/logs
/etc.etc.etc
对我来说,这是一个非常坚实的结构,易于构建和控制。
但作为管理员你可以随心所欲地把事情弄得干净或混乱。
答案3
好的,简单快速的回答。
如果您的系统上的 Web 文件仅供 Linux 系统上的一个用户访问。请使用该用户的主目录 ( ~/
)。
如果您系统上的 Web 文件将被 Linux 系统上的多个用户访问。使用/srv/
。
这正是http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM状态。
以下是引文:
/srv 包含此系统提供的站点特定数据。
指定此项的主要目的是让用户可以找到特定服务的数据文件的位置,并让需要单个树来存放只读数据、可写数据和脚本(如 cgi 脚本)的服务可以合理放置。只有特定用户感兴趣的数据才应放在该用户的主目录中。
奖励:www?ftp?按协议组织?嗯?
正如这里所述http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
- 如果您的网站仅由系统上的一个用户访问,并且仅通过浏览器(http 协议)访问,则:
~/http/your-website-directory/
- 如果您的网站仅由系统上的一个用户访问,并且不仅通过浏览器访问,还通过多种协议(例如 http 和 tcp 和...)访问,那么:
~/your-website-directory/
- 如果系统上有多个用户通过浏览器(http 协议)访问您的网站,那么:
/srv/http/your-website-directory/
- 如果系统上有多个用户访问您的网站,并且不仅通过浏览器,还通过多种协议(例如 http 和 ftp 等)访问您的网站,那么:
/srv/your-website-directory/
咦,为什么不是 www?这是 Apache 时代的遗留。www 没有指定正在使用哪种协议。Debian 至今仍在使用此协议,而例如 Arch linux 使用 /srv/http。
答案4
我开始喜欢为我的应用创建“用户组”的想法。例如,如果我有一个名为“Cowiki”的网站/应用,我会创建一个新用户和关联组,名为“cowiki”,主目录为“/home/cowiki/”,站点代码位于该目录下。这可以是静态站点的简单 HTML,也可以是框架的站点代码(Rails、Phoenix 等),内部组织方式适合应用/框架。
正如我所说,我将这些主目录视为“用户组”。由于它们在访问设置中以组的形式存在,因此我可以根据需要向实际用户授予该组的权限。例如,网站的维护者将拥有完整的 cowiki 组访问权限。
这样做的最好之处,也是主要原因,是因为我总是将我的磁盘分区为“/home”与“/”分开(也可能是分开的驱动器)。这样,我可以轻松备份我的应用程序,如果操作系统需要重新安装,也可以轻松恢复系统(只需在安装期间不要挂载主分区,然后在 fstab 中切换它 - 唯一的技巧是保持用户 ID 相同)。
如果您将 Web 应用程序保存在“srv/”中,您仍然可以通过添加独立于添加新用户的组来获得组的好处。但您必须单独备份“srv/”,并且最好再为其设置一个分区,以使其与操作系统文件分开。对我来说,这似乎有点麻烦,不值得。