问题标签 [fhs]

假设我们有一个名为foo.

如果使用绝对路径：

然后foo$ python setup.py --prefix=/usr/local，我们将拥有/etc/foo.cfg. /usr/local/etc/foo.cfg但是根据FHS我们应该有。

如果我们使用相对路径呢？

那么如果我们使用默认的安装路径，即安装到/usr，我们将拥有/usr/etc/foo.cfg. 又倒霉了。

那么怎么做才对呢？

PS为了避免问题更加复杂，我们假设这个程序 foo不能在非unix环境下运行。

看来你可以把你需要的所有东西都放在 /bin 中，那么我们为什么要打扰 /usr/bin 目录呢？

是否有约定将代表端点的“文件”放置到 Unix 域套接字的位置？

我倾向于把它们放在/tmp/some-application-specific-subdir-name/，但我想知道是否有更常见的地方。

背景是，POSIX不清楚访问此类“文件”的最大路径长度：

sun_path 的大小故意未定义。这是因为不同的实现使用不同的大小。例如，4.3 BSD 使用 108 的大小，而 4.4 BSD 使用 104 的大小。由于大多数实现源自 BSD 版本，因此大小通常在 92 到 108 的范围内。

应用程序不应假定 sun_path 的特定长度或假定它可以容纳 {_POSIX_PATH_MAX} 个字节 (256)。

所以这个对路径长度的“限制”应该被排除在应用程序的文件/路径名配置之外。

我在我的 LAMP 服务器上运行了一个 PHP 脚本，它需要某些文件才能生成 HTML 内容。该脚本可公开访问（即http://example.com/script.php），但该脚本所需的文件必须受到保护。我可能可以将文件放在任何目录之外/var/www，它们会相对安全，但我正在尝试学习 Linux 文件系统，我想使用最合适的位置（根据 FHS）。任何帮助都会很棒。

在我的主目录中，我通常将源代码（无论是解压缩的 tar 球还是 Git/Subversion 工作副本）存储在$HOME/src受 FHS 启发的下方。我想将裸 Git 存储库与这些存储库分开。

是否有任何约定将裸 Git 存储库存储在主目录中？

我有一个 Python 应用程序，当前安装在 Linux Filesystem Standard Hierarchy (FHS)之后。它安装在：

• /usr/bin/（可执行文件）
• /usr/lib/python2.x/site-packages/{appname}/（Python 库）
• /etc/{appname}/（配置文件）
• /usr/share/man/（手册文件）

现在，希望安装此应用程序的非 root 用户可以在没有 root 权限的情况下安装它，并且只有该用户可以运行该应用程序。我们认为最好的办法是将应用程序安装在用户主目录中。
我们已经.{appname}在用户主目录中有一个目录来保存每个用户的配置文件，因为应用程序将配置文件安装在/etc.
我认为使用.{appname}dir 保存所有应用程序文件不是一个好主意，因为目录预先附加了 . 只保留配置文件。可能我会删除该.{appname}目录，因为现在将按用户安装整个应用程序。

2个想法：

• 创建一个{appname}目录并创建子目录 bin 等，lib 和 share/man。
• {app-name}在home下复制Linux FHS并在lib等下 创建子目录
  • 〜/斌/
  • ~/lib/{appname}
  • 〜/分享/人/
  • ~/etc/{appname}

其中哪一种更常用和更推荐？欢迎每种替代方案的利弊。也许是第三种选择？

我见过人们推荐/home/usr/binand /home/usr/local/bin，但我不明白需要在usr此处包含，因为不需要区分基本和非基本二进制文件/库。我更喜欢极简主义。

提前致谢。

我正在为一个库创建一个 debian 包，并想安装二进制示例。我想把它们放在/usr/share/libname，但 lintian 抱怨（arch-dependent-file-in-usr-share）。根据 FHS，这是正确的，但是这些文件可以放在哪里？

我有一个应用程序，它创建了许多 unix 套接字来与它在运行时产生的所有进程进行交互。我认为 /run/appname 将是他们居住的好地方，因为据我了解， /run 应该用于来自应用程序的信息，这些信息仅在应用程序运行时有效。

但我发现

那么为什么普通用户不能在 /run 中创建文件呢？它是干什么用的？我应该坚持 /tmp 吗？

正如标题所问，根据 Linux FHS，在 Linux 操作系统上存储 Python 虚拟环境的技术上合适的位置是什么？

用另一种方式来给出明确的答案：将 Python 虚拟环境的位置与您所服务的数据文件分开是否“技术上正确”？

注意：这个问题与我能找到的最接近的已经提出的问题不同，因为虚拟环境包含库、二进制文件、头文件和脚本。

作为一个额外的复杂因素，我倾向于编写支持互联网访问服务的代码。但是，我不认为这将我的需求与服务的消费者是同一服务器上的其他进程的场景区分开来。我会提到这个细节，以防我对评论的回复包括“网络开发”式的内容。

作为参考，我使用以下文档作为我对 Linux FHS 的定义：http: //www.pathname.com/fhs/pub/fhs-2.3.html

我不相信流行的 virtualenv-wrapper 脚本会建议正确的操作，因为它默认将虚拟环境存储在用户的主目录中。这违反了目录是用于用户特定文件的隐含概念，以及“任何程序都不应依赖此位置”的声明。

从文件系统的根级别，我倾向于/usr（可共享的只读数据）或/srv（由该系统提供的服务的数据），但这是我很难进一步决定的地方。

如果我要接受我的首选反向代理的决定，那就意味着/usr. Nginx 通常被打包到 /usr/share/nginx 或 /usr/local/nginx 中，但是， /usr/ 应该根据 FHS 以只读方式挂载。我觉得这很奇怪，因为我从来没有参与过一个开发如此缓慢的项目，以至于“以只读方式卸载/以写入方式重新挂载，以只读方式卸载/重新挂载”被认为值得付出努力。

/srv是另一个可能的位置，但被称为“特定服务的数据文件的位置”，而 Python 虚拟环境更侧重于提供服务的库和二进制文件（如果没有这种区别，.so文件也将位于 srv 中） . 此外，具有相同需求的多个服务可以共享一个虚拟环境，这违反了描述的“特定”细节。

我相信选择正确位置的部分困难是因为虚拟环境是一个“环境”，它由二进制文件和库组成（几乎就像它自己的小层次结构），这让我觉得下面的某个地方/usr更传统：

根据我的假设和想法：考虑 Nginx 作为 Python 应用程序的反向代理的常见场景。/usr/local/service_name/在使用/srv更频繁更改的文件（例如“静态”资产、图像、css）时放置虚拟环境和源代码（例如application.py）是否正确？

编辑：要清楚：我知道为什么以及如何使用 virtualenvs。我绝不会对项目布局或在开发环境中工作感到困惑。

正如对这个问题的回答，根据 FHS，Unix Domain (AF_UNIX) sockets' 应该放在/var/run

ZeroMQ 套接字呢？应该把它们放在哪里？

谢谢