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

大家好，
我是开发团队野生队的成员 Mandai。

接上
一次不过，这两个目录的配置都比较详细，所以花了不少时间才把它们整合起来。

/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 目录下也存在问题，因此最好在 /etc/local 目录下创建一个子目录并将配置文件放在其中。

 

/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 内存加上每 2 位 4KB 的 RAM，所以如果你有 1TB 的内存，就需要 224MB。这
可不少……

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

另一个大问题是，通过查看内存转储文件能多大程度上确定崩溃原因。
我个人认为无法通过查看内存转储文件来确定崩溃原因，所以我可能不会使用 kdump……

 

/var/games

这是游戏数据的存储区域。
我想你可能不经常在Linux上玩游戏，但例如，Ubuntu预装了上海和数独，为什么不试试呢？

 

/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 是一个在重启后仍然存在的 /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。

这篇帖子已经很长了。

就这样。