FHS 规则控制 Linux 系统目录的布局 - 第二部分

大家好，
我是Mandai，Wild团队负责开发工作的成员。

文接上
不过，这两个目录的配置说明相当详细，需要花些时间才能总结清楚。

/usr

`/usr` 是存放只读共享数据的位置。`
/usr` 下的目录结构也定义得很清晰，所以我们也来看看。

 

/usr/bin

该目录被认为是系统手册 (FHS) 中最重要的目录，它存储着系统的可执行命令。
需要注意的是，该目录下禁止创建子目录。

更详细的规则是，如果安装了 perl、python、tclsh、wish 和 expect 这五个子系统，则必须将可执行文件或指向可执行文件的符号链接放在 /usr/bin 中。

顺便一提，我刚了解到 perl 是“Practical Extraction and Report Language”（实用提取和报告语言）的缩写。

 

/usr/include

此目录存放的是 C 语言的通用头文件。BSD
兼容的头文件似乎放在名为“bsd”的子目录中。

 

/usr/lib

这是一个用于存放共享库和目标文件的目录。
有时，它还会包含一些内部二进制文件，这些文件不应由用户或脚本直接执行。

这和前面提到的 /lib 之间似乎没有明显的区别，事实上在 CentOS 7 中，/lib 是指向 /usr/lib 的符号链接。

每个应用程序都应该在其目录下直接创建一个子目录，并将与架构相关的数据放在该子目录中。
简而言之，不要不必要地污染 /usr/lib 目录。

/usr/lib/sendmail 中仍然存在一些过时的规则，例如要求邮件传输代理 (MTA) 提供指向 sendmail 兼容可执行文件的符号链接。Sendmail
的确很棒。

 

/usr/libexec

这是存放位于 /usr/lib 目录下的内部可执行二进制文件的目录。
我个人觉得，如果他们能明确标明某个文件是库文件还是可执行文件就好了，但似乎有些人就是做不到这一点。

这个“内部可执行二进制文件”似乎是一个经常引发争论的话题，目前似乎还没有定论。

 

/usr/lib<qual>

这是 /lib<qual>同样，这是一个包含依赖于操作系统架构的库的目录。

 

/usr/local

这是系统管理员单独安装软件的安装位置。/usr/local
下的目录结构与 /usr 类似。
自行编译和安装软件时，通常需要指定此目录。

像 yum 和 apt-get 这样的软件包管理系统会将系统安装到 /usr 目录，因此如果您不小心直接从 /usr 目录下安装软件，则存在覆盖现有文件的风险。
当您想要安装不同版本的 PHP 或 Ruby 时，这种情况尤其容易发生。同样，最好将配置文件放在 /etc/local 目录下的子目录中，而不是直接放在 /etc 目录下。

 

/usr/sbin

这是 sbin 目录，用于存放系统二进制文件，但与 /sbin 不同的是，它是存放一些并非必不可少但对系统管理至关重要的命令的地方。

例如，可以使用诸如 iptables、ntpd、crond 和 LVM 等实用的文件系统构建命令。
仅允许可执行二进制文件或指向二进制文件的符号链接；不允许创建子目录。

 

/usr/share

此目录用于存储只读的、与架构相关的数据文件。
字体文件是否与架构相关尚存争议；如果将字体文件放在 /usr/share/fonts 目录下，系统也能识别它们。
手册相关文件存储在 /usr/share/man 目录下。

 

/usr/src

这里用于存储源代码和来自源安装的其他文件。
其主要用途是方便日后参考，但根据软件的不同，卸载时可能需要安装过程中的配置文件，因此安装完成后就将其丢弃是不明智的。

 

/var

/var 目录用于存储可变数据文件。
可变数据包括日志、锁定文件、临时文件以及其他
用于监控和管理 Linux 系统的重要数据。

 

/var/account

这里存储着 sa 命令和 lastcomm 命令收集的日志。history
命令记录已执行的命令，而 sa 命令则侧重于统计数据，例如执行次数和执行时间（这些数据会占用系统资源），lastcomm 命令与 history 命令类似，记录命令的执行情况。

 

/var/cache

应用程序缓存数据存储的目录。

 

/var/crash

这个目录用于存储系统崩溃转储文件。
我很好奇系统崩溃转储文件是什么，但当5.6. /var/crash：系统崩溃转储文件（可选），它显示“当前系统不支持系统崩溃转储文件”。

顺便一提，名为 kdump 的系统崩溃转储工具似乎在 RHEL7 中默认安装。CentOS7
中也安装了该工具。

kdump 的作用是转储系统崩溃时丢失且无法访问的内核内存区域。
这种机制相当复杂，或者说有些强制，因为它涉及到另一个名为 kexec 的命令来启动另一个内核（我们称之为第二个内核；因此，用户使用的操作系统被称为第一个内核），获取第一个内核的内存区域，然后 kdump 将这些数据写入文件。这个过程会在系统崩溃时发生。

运行 kexec 需要的内存是：第一个内核 160MB，再加上每个二进制位 4KB 的 RAM。因此，1TB 的内存需要 224MB 的内存。这可是
相当大的内存量……

此外，由于不同的内核会同时运行，预计 CPU 会被一定程度地占用，因此也必须注意这一点。

另一个主要问题是，检查内存转储是否真的有助于找出崩溃的原因。
就我个人而言，我怀疑仅凭查看内存转储文件能否找到原因，所以我可能根本不会使用 kdump……

 

/var/games

这里存储着游戏相关的数据。
虽然你可能不经常在 Linux 上玩游戏，但例如 Ubuntu 就预装了 Shanghai 和 Sudoku 这两款游戏，何不试玩一下呢？

 

/var/lib

这是存储已安装系统数据的区域。
例如，如果使用 yum 安装 MySQL，则所有模式数据都位于 /var/lib/mysql 目录下。

 

/var/lock

锁文件就位于这里。
然而，锁文件的位置因系统而异，在 MySQL 中，套接字锁文件位于 /var/lib/mysql 目录下。我很好奇
这是因为我们正处于向 FHS3.0 过渡的时期，还是他们根本就没打算更改？这有点令人费解。

 

/var/log

每个管理员都应该检查这个目录。
内核日志和各种应用程序的日志通常都存储在这里。

根据日志类型的不同，有些日志可能只有 root 用户或具有同等权限的用户才能访问，因此根据管理需要，可能需要对此进行调整。

 

/var/mail

这里存储着发送给每个用户的电子邮件。
但是，根据操作系统的不同，邮箱可能配置在 /var/spool/mail 目录下，而该目录可能是一个符号链接。

 

/var/opt

此目录被指定为存储在 /opt 目录下的软件的可变数据的存储位置。
静态文件被指定存储在 /etc 目录下，这给人一种配置文件散落在各处的错觉。
可执行文件存储在 /opt 目录下，而安装在 /opt 目录下的软件包的文件存储位置则被严格定义（笑），这给人一种它们被边缘化的错觉……

 

/var/run

此目录的存在是为了兼容性考虑，专为按照旧版 FHS 规范设计的系统而保留。
其功能现已由 `/run` 目录取代，在 CentOS 7 中，它以指向 `/run` 的符号链接形式出现。

原文主要关注访问 utmp，其中大约一半的内容都与 utmp 有关。

 

/var/spool

/var/spool 是一个用于存放等待处理的临时数据的目录。它
比 /var/tmp 更具体一些，可能指的是等待后续处理的数据。

/var/spool/mail 包含发送给本地用户的电子邮件，而 /var/spool/cron 下是包含为每个用户名注册的电子邮件的文本文件。

 

/var/tmp

/var/tmp 目录被指定为临时目录，即使重启系统也不会删除。
因此，当处理此目录中的文件时，应始终使用创建这些文件的应用程序将其删除。

 

/var/yp

这是存放 NIS（网络信息服务）数据的目录。

之所以叫“yp”，是因为NIS的前身系统叫做Sun Yellow Pages，这是已倒闭的Sun Microsystems公司的遗留名称。由于
商标问题，“Yellow Pages”这个名字不能再使用了，所以NIS沿用了这个名称，并一直沿用至今。

更复杂的是，还有一个名为 /var/nis 的目录，这里没有提到，但它确实存在，并且是 NIS+ 使用的目录，因此 NIS 不使用它。

更详细地说，NIS 是一种用于在网络内共享用户帐户和网络配置信息的软件。
目前使用的类似系统是 DNS，但 DNS 专注于网络本身，因此可以说 NIS 的范围更广。

乍一看，它似乎非常方便，但它开发于 20 世纪 80 年代，当时公共网络尚不发达，不足以吸引恶意攻击者，因此安全的概念也并不存在。
此外，NIS 只能管理单个域，而且部署起来非常简单。

NIS+克服了NIS的不足，支持对多个域进行分层管理，并通过加密技术集成了强大的安全功能——这是一个改进颇多的系统。
然而，它仍然使用DES加密，因此仍然存在一些安全漏洞。

当我查阅相关资料时，发现只有关于 Solaris 的页面，而且这些资料已经超过 15 年了，所以看来在 21 世纪的今天，即使不知道 /var/yp 是什么，你也可以操作 Linux。

这篇帖子已经很长了。

就这样。