4. Linux 目录层级结构：面向软件组件
到目前为止，所有讨论都与操作系统无关。在 Linux 上，四软件组件理论体现在其目录结构中，该结构在 文件系统层级标准中进行了分类和记录。FHS 是 LSB (Linux 标准库) 的一部分，这是一件好事，因为整个行业都在朝着它发展，并且是所有发行版持续关注的问题。FHS 定义了 Apache、Samba、Mozilla、KDE *以及你的软件*的每个部分应该放在哪个目录中，并且在考虑开发你的软件时，你没有任何其他理由不使用它，但我会给你更多的理由。
FHS 是一个标准，没有标准我们就无法生存
这是最基本的操作系统组织，它与访问级别和 安全性相关，用户可以直观地找到每种类型的文件，等等。
让用户的生活更轻松
最后一个原因已经证明了 FHS 的采用是合理的，所以 始终使用 FHS !!!
关于 FHS 的重要性和共享相同目录结构的更多信息可以在 Red Hat 网站上找到。
4.1. FHS 摘要
- /usr/bin
所有用户都可以访问的可执行文件的目录（每个人都在他们的目录中拥有此目录$PATH）。你的软件的主要文件可能就在这里。你永远不应该在此文件夹下创建子目录。
- /bin
和上面类似/usr/bin，但在这里你只会找到引导过程至关重要的可执行文件，它们简单且体积小。你的软件（作为高级软件）可能没有任何东西可以安装在这里。
- /usr/sbin
- /sbin
- /usr/lib
包含 /usr/bin 和 /usr/sbin 中可执行文件的动态库和支持静态文件。你可以创建一个子目录，例如 /usr/lib/myproduct 来包含你的辅助文件，或者只有你的软件才能访问的动态库，而无需用户干预。此处的子目录可以用作 插件和扩展的容器。
- /lib
和上面类似/usr/lib但包含引导过程中需要的动态库和支持静态文件。你永远不会在/bin或者/sbin找到需要此目录之外的库的可执行文件。内核模块（设备驱动程序）位于/lib.
- /etc
包含配置文件。如果你的软件使用多个文件，请将它们放在一个子文件夹下，例如/etc/myproduct/
- /var
该名称来自“variable”，因为此目录下的所有内容都会频繁更改，并且包系统 (RPM) 不会对其进行控制。通常/var挂载在单独的高性能分区上。在/var/log日志文件会不断增长。对于 Web 内容，我们使用/var/www，等等。
- /home
包含用户（真人）的主目录。你的软件包绝不应该在此处（在安装时）安装文件。如果你的业务逻辑需要创建一个特殊的 UNIX 用户（不是真人），你应该在/var或其他地方外部/home为他分配一个主目录。 请永远不要忘记这一点。
- /usr/share/doc, /usr/share/man
“share”一词的使用是因为/usr/share下的内容与平台无关，并且可以在网络文件系统中的多台机器之间共享。因此，这是手册、文档、示例等的位置。
- /usr/local, /opt
这些是过时的文件夹。 当 UNIX 没有包系统（如 RPM）时，系统管理员需要将一个可选（或本地）软件与主操作系统分开。 这些是用于此目的的目录。
你可能会认为将你的软件（作为一个整体）分成多个部分，而不是将所有软件都保存在一个独立的目录下，是一个坏主意。 但是 包系统 (RPM) 有一个数据库，可以非常专业地为你管理所有内容，负责配置文件、目录等。 如果你使用 FHS 传播你的软件，除了用户友好性之外，你还会为系统管理员配置它带来一种直观的方式，并在性能和安全性方面更好地工作。
4.2. 使用 FHS 的示例
现在我们知道软件的每个部分必须安装在哪里，让我们回顾一下应用于 FHS 的通用组件表。
表 2. 应用 FHS 的相同软件
| 软件本身 | 配置 | 内容 | 日志、转储等 | |
|---|---|---|---|---|
| 数据库服务器 | /usr/bin/, /usr/lib/, /usr/share/doc/mydb/, /usr/share/doc/mydb/examples/ | /etc/mydb/ | /var/db/instance1/, /var/db/instance2/, 等等 | /var/db/instance1/transactions/, /var/log/db/access-instance1.log, /var/log/db/access-instance2.log |
| 文本编辑器 | /usr/bin/, /usr/lib/, /usr/lib/myeditor/plugins/, /usr/share/myeditor/templates/, /usr/share/doc/myeditor/ | $HOME/.myeditor.conf | $HOME/Docs/ | $HOME/.myeditor-tmp/ |
| MP3 生成器 | /usr/bin/, /usr/lib/, /usr/lib/mymp3/plugins/, /usr/share/doc/mymp3/ | $HOME/.mymp3.conf | $HOME/Music/ | $HOME/.mymp3-tmp/ |
| Web 服务器 | /usr/sbin/, /usr/bin/, /usr/lib/httpd-modules/, /usr/share/doc/httpd/, /usr/share/doc/httpd/examples/ | /etc/httpd/, /etc/httpd/instance1/, /etc/httpd/instance2/ | /var/www/, /var/www/instance1/, /var/www/instance2/ | /var/logs/httpd/, /var/logs/httpd/instance1/, /var/logs/httpd/instance2/ |
| 电子邮件服务器 | /usr/sbin/, /usr/bin/, /usr/lib/, /usr/share/doc/mymail/ | /etc/mail/, /etc/mailserver.cf | /var/mail/ | /var/spool/mailqueue/, /var/logs/mail.log |
4.3. 开发者，请勿安装在/opt或者/usr/local !
如果你是系统管理员，本节不适合你。 这是针对开发人员和打包人员的主题，旨在让系统管理员的生活更轻松。
和/opt和/usr/local目录由系统管理员用于手动非打包文件（没有 RPM）的软件，正是为了不丢失对这些文件的控制。 请注意此文件夹与系统其余部分的隔离程度。
使用RPM 是不同的。 RPM（或任何其他包系统）本身就是一个安装“过程”。 它在他的数据库和安装前和安装后操作中进行了自我记录，从而可以进行全面控制。 使安装独立于执行安装的人，从而将安装变成一个业务流程。
基于将文件复制到/opt或者/usr/local的安装远远不能提供 RPM 提供的组织、系统可见性和控制。 我可以说/opt和/usr/local当所有软件都进行 RPM 化时，它将被淘汰。
对于 Linux 的发展和普及（尤其是在桌面战场上）来说，非常重要的是，开发人员停止使用这些糟糕的目录，并开始使用 FHS。 阅读本节后，如果你仍然认为这些文件夹对业务有益，请给我发送电子邮件。
完全安装在一个目录下的产品使用自包含方法，该方法存在几个问题
强制用户更改环境变量，例如$PATH和$LD_LIBRARY_PATH以便轻松使用你的产品。
将文件放在非标准位置，从而使系统集成复杂化，并使将来安装你的产品的扩展变得更加困难。
系统管理员可能没有在这些分区中准备磁盘空间，从而在安装时产生问题。
只有对于没有命令行概念的纯图形应用程序，这才是可接受的方法。 这就是为什么它在 Windows 中被广泛接受的原因。 但是...
...即使使用这种方法，你也不能避免在标准位置安装或更改文件，例如，让你的图标出现在用户桌面上。
许多开发人员认为，“自包含”方法使他们可以同时使用同一产品的多个版本，用于测试目的或其他目的。 是的，同意，有了这个或地球上任何好的理由。 但请记住，高质量软件（或商业级软件）的目标是让最终用户感到实用，而不是让他们的开发人员和测试人员感到容易。 邀请自己去拜访一个没有经验的用户（但有潜力的客户），并观看他安装你的产品。
开发者，不要害怕根据 FHS 传播你的文件，因为 RPM 会密切关注它们。
如果出于商业原因，你想让用户同时使用你的产品的多个版本（或任何其他原因），请创建一个 可重定位的软件包，这在 Maximum RPM 书中进行了描述。 还要注意使用此功能的含义，在同一本书中进行了描述。
Red Hat 及其衍生发行版始终使用目录标准，而不是/opt或者/usr/local。阅读 Red Hat 关于此主题的说明，并思考一下。
 | 对于可移植到其他 UNIX 系统的开源软件，其 Makefile 必须将标准安装路径设置为/usr/local，这是出于兼容性考虑。但也必须提供选项，并引导打包者使用 FHS 规范创建软件包。 |